On 22/10/2007, Giovanni Corriga <giovanni at corriga.net> wrote:
> Il giorno lun, 22/10/2007 alle 10.49 +0300, Igor Stasenko ha scritto:
> > On 21/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> > > On 10/21/07, Igor Stasenko <siguctua at gmail.com> wrote:
> > > > If you need to synchronize access to some object you simply can't
> > > > avoid that - at any level of abstraction (being in Erlang or OS, or
> > > > assembler).
> > >
> > > That's the point: you *don't* have synchronized access to any object.
> > > All you have is messages.  Think of it as an OO view of processes.
> > > You can't see what's inside, you can only ask the process to do things
> > > on your behalf.
> > >
> >
> > Again, a question raised: how to ensure that messages are passed in
> > correct order and  make sure that messages are delivered?
> > Now lets look inside: to make it working properly, you need to
> > implement a message queue. And queue means that you must make an
> > 'enqueue' and 'dequeue' operations  synchronized.
> > And that's exactly what i mean: even if you hide the concurrency
> > problems from the eyes of developer, this is not means that problems
> > are gone: now you have to deal with them by own.
> > If you know another way(s) how to make proper message passing scheme
> > without using synchronized object (such as queue), i am all ears.
>
> The Erlang way: don't care about the order of arrival of the messages,
> and let the developer care about that when it's important.
>

Yes, a simple example when i need to have correct order:
Collection>>do:

to print an array i'll have all items ordered from start to end , not
in random order.

And of course there are cases, when i don't need to have items
iterated in specific order. When i simply need to visit all items in
collection to send a message to them.

So, we need at least 2 messages to reflect a different behaviour:
#do:
and
#orderedDo:

and that's only the simplest case...

>         Giovanni
>


-- 
Best regards,
Igor Stasenko AKA sig.