the OO metaphor

Vlad Dumitrescu vladdu@REDACTED
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 
this issue.

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 
sees first...

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 :

More information about the erlang-questions mailing list