Paradigms / OO vs CO [LONG]

Vlad Dumitrescu (EAW) <>
Fri Mar 7 11:54:17 CET 2003

> I think this is the germ of a good model, and that, appropriately
> developed, it could fit between OO and CO.  Decompose the problem into
> objects which may or may not have agency (processes.)  But the hard
> part is making sure that objects can be treated the same by other
> objects, regardless of whether they are dynamic or not.  I'd like to
> see something more transparent than "concurrent objects" or "Erlang
> with object extensions" - either of which seems to be a short-sighted
> approach where features with essentially incompatible 
> assumptions would
> get slapped onto a pre-existing framework - rather than generating a
> smooth & novel synthesis of the two.

I have been thinking along those lines too, although not as much to the point. I am not sure what you mean by "something transparent" when handling dynamic and static objects (or things).

IMHO, if one uses the usual pattern of wrapping gen_server calls in function calls, then just the same thing can be done for an inert object, like for example a record. We have a module that defines some static data, and also the way it is accessed. The first argument will be the data, instead of a Pid when processes are involved. If one agrees to use this first argument as an opaque reference, then it is as transparent as it can be, with no changes to the language or VM.

However, I think it was you Chris that wanted the message passing to be more visible. Then transparency would mean that writing "Not_a_pid_or_atom ! Term" will have to translate into a regular function call (supposedly the Not_a_pid_or_atom data will have information about which module and so). Then again it will be transparent, with some changes. (However having a static_thing:start() might be confusing)

Or am I missing something here?

*** ***
Is it a good thing to hide the difference, or is it important to know apart dynamic from static entities? I don't know, but my gut feeling is in favor of the latter.
*** ***

A note about static objects, one question would be how to handle extending their functionality, instead of a class hierarchy. I think this can be done easily, and without disturbing too much. One simple (simplistic?) way might be using delegation to another module. Syntactic sugar can make it as simple as
	-delegate(other_module, [fun1/3, fun2/0]).
which will automatically create function definitions for fun1 and fun2. 

I think I can already hear voices saying "It's not good, you're spreading the functionality over several modules, and we want to be able to see what's happening by reading just one". To that I'd answer that in practice one-module-only functionality is quite rare for less-than-most-simple cases. There are implied dependencies in complex cases and they aren't visible in the code. Take Joe's femto-web-server for example: the three modules are indeed separate, but they are meant to work together (except for tcp_server which is generic).

best regards,

More information about the erlang-questions mailing list