Re: LUTask, luatask, encapsulation vs isolation

[Chris Pressey <cpressey@...>]

On Sat, 29 Jan 2005 20:24:45 -0800
Chris Pressey <cpressey@catseye.mine.nu> wrote:

> On Sun, 30 Jan 2005 02:16:03 +0100
> PA <petite.abeille@gmail.com> wrote:
> 
> > 
> > On Jan 30, 2005, at 01:57, PA wrote:
> > 
> > > -- The 'magic' incarnation
> > > local aTask = LUTask.new( aConvolutedObject,
> > > aConvolutedObject.doIt() )
> > 
> > Ooops... I just realized that I cannot pass the function itself
> > right  there... as this will have the unfortunate effect of
> > executing it...
> 
> Why not
> 
>   LUTask.new(aConvolutedObject, function() aConvolutedObject.doIt()
>   end)
> 
> ?
> 
> For that matter, why wrap tasks around objects in the first place? 
> This isn't Java.  :)

Sorry - the "send" and "paste" shortcut keys in my mail client are a tad
too close together - I was going to say something more here...

Object-oriented languages have a nasty tendency to model everything as
an object (because that's all they know.)  Functional languages are
equally prone to modelling everything as a function.  Personally, I like
Lua because it is closer to being multiparadigmal, but without being
bloated.

A task(/thread/lightweight process/call it what you will) is a
function that runs "while" other tasks are also running.  So, I
think it makes the most sense to model tasks as functions.

A task does need some way to communicate with the other tasks - and
rendezvousing through some object would be one way to communicate with
other tasks, but it's not the only way.  Personally, I like message
queues.  IMO they lead to a much more understandable program layout than
mutexes and semaphores and such do.  And for such a scheme,
http://luaforge.net/projects/luatask/ looks like it has a lot of
potential.  It seems to come very close to what Erlang offers, in
spirit, minus a few things like pattern-matching on incoming messages.

When talking about object-orientation, the subject of encapsulation
comes up a lot.  I don't think encapsulation is a goal unto itself,
though; it is one way to achieve something more important - that is,
isolation.  We don't want anything in thing A to affect anything in
thing B - except, perhaps, for a very narrow, well-defined protocol
between the two things.

The best way, IMO, to isolate two things is to have them on different
processors.  The next best way is to have them in different protected
memory spaces on the same processor.  The third best way is to have them
in the same memory space, but running on a virtual machine that doesn't
allow them to access the same memory (this is Erlang's model.)  The
least best way is to have them share memory and force the programmer to
correctly manage that state themselves.  This, unfortunately, seems to
be the dominant model in the programming world at present...

-Chris