Erlang hints from an CO junkie

[Vlad Balin]

> > Well, from the design point of view, you're describing OO
> approach in terms
> > of Alan Key.
> > "Objects are the base building blocks, objects has the state, objects
> > communicate
> > with each other using messages." See citate below.
>
> I don't really understand this kind of statement.
>
> 1) In OO design you must identify the different objects involved
> 2) In CO design you must identify the different concurrency
> patterns involved
>
> 1) in not the same as 2)

On a high level of your design you use processes as a unit of encapsulation.
Just substitute 'object' with 'process'. What about concurrency, the
semantic
of 'objects' according to Key imply concurrent message processing. Key
even use the 'protocol' term to describe an object interface - very close to
the things you're saying.

Differens is only in terms. Your explanation implies that there's no
difference
between object and process. To illustrate the difference, you could provide
an example when 'concurrency pattern' is _not_ the unit of encapsulation,
but
you clearly stated that it always _is_.

>   I also dislike this "everything is an object" way of thinking.
I also dislike this way of thinking. But this is an ideology of Smalltalk
only.
You obviously don't have to make everything an object to use OO paradigm.

>    As for the idea of bundling together data structures and methods into
> the same unit of abstract and calling this an object is even sillier.
I can't understand it. Could comment more on this?

First, you just suggested to do so when using processes as encapsulation
units,
which are accessiblie via the defined protocol only, and implementation
(with
underlying data structures) is hidden. Sending message is almost equivalent
to
calling a method.

Second, you (I guess) consider using of Erlang behaviours as good practice.
This is another example of abstract data types application.

And third, Erlang standard library contains a lot of examples of binding
'methods' and
'structures' together. queue, gbtree, sets, etc.
It's normal to access wierd data structures like Okasaki's queue
throung the abstract function's interface, cause it'll simplify the things.
You disagree?

>    In my way of thinking we can model things using the following
> things.
>
>     a) Pure data structures (described by types)
>     b) Pure functions which transform data structures into different
>        data structures
>     c) Processes. Processes are little virtual machines. They have state
>        (state is just some class (a) data). You can send them
> messages (messages
>        are class (a) data structures). They might respond with messages.
>        They are independent - if they crash no other processes should be
>        affected.
Ok.
>     Data structures (a's), functions (b's) and processes (c's) are all
> fundamentally different types of things - they should not be mangled
> together and called objects.
Ok, we'll never call them 'objects' :). Does it change anything?
An idea behind 'objects' is to hide an implementation details upon an
abstract
interface of a set of functions (messaging protocol).

That's exactly what _you_ do when you
1) Define interface to Okasaki Queue using (b) class thing (pure functions).
2) Create an abstraction of a City using (c) class thing (process). You also
mentioned that City process can spawn 1000 processes to model houses. Fine,
you can think of them (I know you'll consider it wierd :), but...) as
'aggregated
objects(processes)', since they are not visible to the user of the City
process.
What you did? You created an abstraction for City, with implementation
details
hidden; _this_ is called object, or 'abstract data type' instance, or
whatever you
like.

P. S.: Our messages tends to be quite long, :) so I'm going to answer to the
second
part later.

Sincerely yours,
Vlad Balin.