Fw: Paradigms / OO vs CO [LONG]

[Vlad Dumitrescu]

* Sorry if this gets to be a duplicate, the earlier copy seems to be stuck
in cyberspace...

> 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,
 Vlad