Process Wasting (was: OO vs CO)

[Chris Pressey]

(right now I'm having to resort to webmail, so, apologies if the
formatting on this message turns out a bit munged)

Vlad Dumitrescu wrote:
> > [me]
> > 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).

Neither do I.  Damn.  Sorry.  I typed that too quickly.

Actually, I've found that term "transparent" to be one of the more
misused, so I'm REALLY kicking myself for that one.  In this industry
people have a tendency to say "transparent" when they mean "seamless"
(which is really semantically closer to "opaque"...)

So I think I meant seamless there.  So, no, you're not missing
anything.

> [...]
> *** ***
> 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.
> *** ***

It's a double-edged sword.  You lose some, you gain some...

Actually, something I meant to address, but didn't really, was that an
object can go from static to dynamic back to static (like the forklift,
when you turn it on or off, or the candles, when they're lit then
extinguished.)  I'd hate to have to remodel/rewrite something, after
deciding that it should be the other.

Of course, if you take a longer view, I guess the problem disappears;
an
object that goes from static to dynamic, is in the overall analysis -
dynamic.

In other words - it's easier to simulate object-ness with a process,
than it is to simulate process-ness with an object.  If you want an
"inert process" with no dynamic behaviour at all, you can just say

  listen() ->
    receive
      _ -> listen()
    end.

I guess my real contention is with the fact that this is a waste - even
if an Erlang node *can* happily handle 7000 concurrent processes - why
push it that far, if 60% of those processes aren't really doing squat?

That's probably my own hang-up at this point, though - wasting
processes is probably justifiable, if it makes the model more cohesive
- which it does, here.

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

Delegate, inherit, override, whatever you want to call it, I think it'd
be a good thing to have.  Just to stress it - I imagine it would be
syntactic sugar for

  default(Function, Args) ->
    apply(other_module, Function, Args).

Where default/2 is a function that is called in a module, when an
undefined function is specified to be called in that module, instead of
raising an exception.  Again, not very original perhaps - many of the
ideas for things that I think would be good in Erlang, show up in Perl
in some form - but flexible and very much in tune with the "you have
complete control over error handling" tenet.

Mainly I like this because it seems to address the biggest process
waste that I can forsee: specialization.  It hardly seems worth it to
use processes for "front-ends" which simply redirect "traffic" - when
we can do that in a much simpler way.

Seems to have something to do with what I said before, how a process
which is just translating CR's to LF's isn't very interesting
(therefore, why is it a process?) - but one which accepts arbitrary
chunks of text and repackages it into lines, it's very easy to see how
making it a process increases clarity and organization, well,
phenomenally really...

> 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".

But we also want modules to be small, and "self-contained"... there's
only so much you can expect.  Modules are modular (duh? :) so they'll
always have external references.

> 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).

Exactly.

> best regards,
> Vlad

-Chris


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca