Extending Functionality: gen_server_ext
Vlad Dumitrescu (EAW)
Vlad.Dumitrescu@REDACTED
Fri Mar 21 11:22:01 CET 2003
Hello,
> From: Jay Nelson [mailto:jay@REDACTED]
>Chris and Vlad discussed:
>> Extensions to gen_server to support "behavers" and pseudo
>> inheritance call chains ...
> Chained processes - deep inheritance
<...snipped...>
> Interface amalgam - shallow inheritance
<...snipped...>
You make some interesting observations, and I will have to sit down
and think about it properly before replying. Right now, I'd like to
make some observations of my own.
What I think it would be best (inspired from both your and Chris'
ideas) is some kind of behavioural composition. It might involve a
separate process per simple behaviour, or maybe thay can be combined
in a single process. It was the latter I was thinking about when
writing gen_server_ext: one process implementing several
behaviours. But this latest idea of the Amalgam, is really interesting.
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, and I can
(if I want) to override some of the functionality to better suit the
button's needs. There will be some callbacks that the behaviours need:
for example 'mouse_over' can call button:on_mouse_over(), where the
pointer can be set to a hand instead of an arrow. If the button shall
become inactive, it will be enough to just disable it's 'clickable'
behaviour.
Potential problem: how to ensure that these behaviours do not have
overlapping interfaces? (i.e. message tags or callback names that are
the same)
Maybe a better analogy than "objects" is "components". Use behaviours
(as processes or as modules) as components, building stones for more
advanced components and finally whole systems. This didn't work so
well for OO components, but this doesn't mean the basic idea is
flawed.
Of course, all this can be done by hand, but it seems like a general
enough functionality to implement once, test properly and reuse. Just
like gen_server, for example :-)
best regards,
Vlad
More information about the erlang-questions
mailing list