Extending Functionality: gen_server_ext

Vlad Dumitrescu <>
Sat Mar 22 22:51:46 CET 2003


Hi all,

First, I got a link from Vladimir Sekissov (thanks a lot!) for
something very close to what I in mind (but not as well-thought as in
the paper, of course). I wouldn't stop at just GUIs, however.
http://citeseer.nj.nec.com/gansner93multithreaded.html

From: "Chris Pressey" <>
> > What I'd like to be able to do is create a process by specifying
> > several interfaces/behaviours it will support, a GUI related example
> > might be for a button: I need let's say 'drawable', 'clickable',
> > 'mouse_over'. Just by naming them, I get the functionality,
> 
>   -module(my_button).
>   -behaviour(drawable).
>   -behaviour(clickable).
>   -behaviour(mouse_over).

Not really, this means we have a module where we will have to
implement callbacks for all these behaviours. If 80% of those are just
delegating the work away, then I think it's a waste of effort. Also
you can't dynamically add/remove behaviours.

Also to Shawn: I agree that being able to see from the code what a
call will result in is good, but it is possible (and done) today too
to have a server holding a list of callbacks that clients have
registered - you can't know in the code which ones will be present at
runtime. I don't think it's a fundamental difference... Or one could
send a Fun to be called in another process - if that fun was received
from somewhere else, then it can't be traced without scanning the
whole system. I couldn't see any warning in the Programming Rules
about this...

Otherwise, Chris' and other's comments are pertinent and I mostly
agree (where I don't, it really is a matter of taste). I will repeat
that I don't think this suggestion I made is The True Solution (tm),
just like I don't think Erlang is perfect and will never need any
improvements.

One way that will probably please most, is the one Jay proposed first,
to use many simple cooperating processes (and this is also done in the
paper mentioned before). A remaining question is how to easily connect
together these processes so that they work as they should. I am
thinking about it.

BTW, a not directly related question: let's consider a process that
receives input (messages) and just dispatches them to a number of
registered clients. Is this okay to do? It's not possible to trace
where the messages go from just inspecting the code, but I think it is
a very useful functionality.

best regards,
Vlad



More information about the erlang-questions mailing list