the OO metaphor
Thu Nov 30 00:31:53 CET 2000
Wow, what a response! :-) Always nice to be able to start a debate!
I sat and told a bedtime story to my son, while thinking about this
OO/Relang issue... and when opening the mail and reading it, I was struck by
the similarity between what I wanted to say and what Ulf said.
Polymorphism and up to a point inheritance can be easily simulated in
Erlang, if one uses direct messages to processes. But the recommended and
better way is to have a functional wrapper that will communicate with the
process, and by using it one has to rewrite all the delegation functions,
which is tedious and a maintenance problem.
The similarity I was talking about lies in that I came up thinking in terms
of interfaces too, and inheriting/extending them.
My 10 öre of inspiration tonight amount to the insight that there are 2
logical kinds of modules: function libraries (like lists) and interfaces to
processes. The latter correspond roughly to an object interface in the OO
metaphor, while the former are just a gathering of related code. The latter
are also the ones one would want to be able to extend transparently (i.e.
inherit from the object and use it polymorphically).
$inherit_api (or something similar) would be a nice and clean way to handle
On the other hand, interfaces that are shared like this create also
problems: for example, what happens if an interface that is extended by many
other has to be changed in a non-compatible way? There are solutions, of
course - the point is that there may be more things to think about than one
Just don't ask me where do I want to get to with all this... I wish I
remembered the conclusion myself! :-) To comment on Ulf's system_erlang
ideas, I think those mechanisms would be useful, and might even provide
support for more things than those they are intended for.
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
More information about the erlang-questions