[erlang-questions] OTP application design

Kirill Zaborski qrilka@REDACTED
Tue Jun 12 21:33:36 CEST 2007

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
I know  it's just a habit of static typing :)

On 6/12/07, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> Hi,
> On 6/12/07, Kirill Zaborski <qrilka@REDACTED> wrote:
> > Vlad, thanks for your explanations but you missed the point :)
> Sorry!
> > But I have also a task (for testing purposes) to write a worker emulator
> > (apart from actual workers) or maybe a couple of emulators with a
> different
> > logic. And those emulators should act like normal workers (which will be
> > gen_server+API) so they must implement handle_call({work,Data}) and I
> can
> > not use some behavior to declare API common to both "normal" worker and
> > worker emulator.
> Why can't the API be common?
> Let me see if I understand correctly. You want the workers to have a
> common API, but be able to run code from two (or more) modules, where
> one is the "real" one and the other is the "emulated" one?
> Put the API in module 'worker'. Then implement two gen_server
> behaviours, 'real_worker' and 'emulated_worker'. When creating a
> worker, use the appropriate module name as the 'Module' argument to
> gen_server:start_link/3. Done! The rest of the API just uses a pid and
> doesn't care which module implements the functionality.
> regards,
> Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070612/87d967b6/attachment.htm>

More information about the erlang-questions mailing list