the OO metaphor

[Peter Andersson]

Hi Vlad,

I remember reading a paper on this subject (or something similar) a few years
back. It was written by Torbjörn Keisu (Ericsson Software Architecture Lab), I
believe. Now, I can't remember exactly what OO issues were discussed in that
paper. What worse is, I can't even find it anymore! Does anyone know where it's
stored?

I'm writing a simple event driven simulator "engine" in Erlang at the moment,
just for fun (nerd pride! :-). I've done similar things in Java and C++ before
and I thought I was going to run into the "oh, I really wish I had inheritance
for this" feeling quite often. I thought I would think up smart alternatives (or
resembling constructs) along the way. An OO programming style using ADTs is
easily accomplished in Erlang. You don't need to have a "one object per process"
model for this. Normal "buy-sell" relations between objects are also easily
handled. It's inheritance and polymorphy that might be hard to do, but so far I
haven't really given that so much thought (proves how much planning went in to
this project before execution, huh! ;-).

Now, I probably will run into more of these questions as I start writing a
simulator application on top of the engine (that's really when I start modelling
"real world" entities and relations). As of yet I've only actually dealt with
concurrency issues. For many of the features I'm trying to implement in the
engine, concurrency is a must and of course I find that Erlang is the perfect
language for the job! My idea is, by the way, to allow objects to be implemented
to run on an engine process or on one or more dedicated processes in a dynamic
fashion. I'm looking forward to start experimenting with this, but so far I'm
only half way with the engine. It's great fun!

  /Peter


Vlad Dumitrescu wrote:
> 
> The "thread thread" is very interesting, and talking about OO reminded me of
> an idea I got... I think it's not a very bad one, so I will share it with
> you, to see what you think.
> 
> The OO methodology can be easily applied to Erlang, once one gets to ffel
> the pulse of the language. There is however one thing that is missing, and
> that I think it could be useful. That thing is inheritance.
> 
> The natural way for inheritance to be implemented in Erlang isn't the C++
> way, but the CLOS way, through some kind of generic functions. A better name
> than inheritance might be "shared implementation between modules". An
> example might be appropriate.
> 
> -module(base).
> 
> fun1(blip) -> foo;
> fun1(A) -> {empty, A}.
> 
> ==== and (the syntax is just a proposal)
> 
> -module(base_extended).
> -extend({base, [fun1]}).
> 
> fun1({help}) -> hohoho;
> -inherited(). %% need not be always present
> fun1(_) -> false.
> 
> The meaning would be that the clauses of base:fun1 are imported into the
> ones of base_extended:fun1, allowing some of them or all to be overriden.
> The gain would be for example that when extending the lists module, one only
> needs to write implementations for the functions that are different.
> 
> There are problems with the above way of doing it, I know. One might want to
> reorder clauses, or to keep only part of the inherited ones... But it is the
> general idea that I'd like to discuss.
> 
> As someone said earlier (Ulf I think), this creates dependencies between
> modules. This isn't always a Good Thing. But on the other hand, when writing
> a gen_server, there is a dependency upon the gen_server module... When
> trying to implement a module based on another (and that can be used instead
> of the other), avoiding to write 50 stub functions that just delegate he job
> for the 2 or 3 that need rewriting is kind of a waste. Plus att the compiler
> might be able to optimize the calls.
> 
> It's almost midnight, and I'm not very sure I managed to explain properly.
> 
> I look forward to find out what a wonderful idea you all thin this is :-)
> 
> Or alternatively, to find out why it is such a bad idea!
> 
> regards,
> Vlad
> _____________________________________________________________________________________
> Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com