Yes, I mean the same but th point is that there will be no "contract", and logic implemented in both gen_servers should be checked manually (no common interface except gen_server behavior) so if I create new function and new handle_call clause in 
worker.erl I must remember to add the same clause in emulator.erl<br>I know  it's just a habit of static typing :)<br>Thanks.<br><br>Regards,<br>Kirill.<br><div><span class="gmail_quote">On 6/12/07, <b class="gmail_sendername">
Vlad Dumitrescu</b> <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>On 6/12/07, Kirill Zaborski <<a href="mailto:qrilka@gmail.com">qrilka@gmail.com</a>> wrote:<br>> Vlad, thanks for your explanations but you missed the point :)<br><br>Sorry!<br><br>> But I have also a task (for testing purposes) to write a worker emulator
<br>> (apart from actual workers) or maybe a couple of emulators with a different<br>> logic. And those emulators should act like normal workers (which will be<br>> gen_server+API) so they must implement handle_call({work,Data}) and I can
<br>> not use some behavior to declare API common to both "normal" worker and<br>> worker emulator.<br><br>Why can't the API be common?<br><br>Let me see if I understand correctly. You want the workers to have a
<br>common API, but be able to run code from two (or more) modules, where<br>one is the "real" one and the other is the "emulated" one?<br><br>Put the API in module 'worker'. Then implement two gen_server
<br>behaviours, 'real_worker' and 'emulated_worker'. When creating a<br>worker, use the appropriate module name as the 'Module' argument to<br>gen_server:start_link/3. Done! The rest of the API just uses a pid and
<br>doesn't care which module implements the functionality.<br><br>regards,<br>Vlad<br></blockquote></div><br>