Erlang hints for an OO junkie

[Vlad Balin]

>> So what is wrong here? Processes should _not _ be widely used as unit of
>> incapsulation, or you will not take benefit of referential transparency.
And
>> if you do so,
>> you would better use non-functional language.

> You forgot to suggest what the OP should use in place of processes. He
> seems genuinely interested in what the 'right' way to do things is.  I'm
> interested in the results of the discussion too, it's educational as I
> haven't been using Erlang very long myself.

> Thankyou
> --
> David N. Welton

I'm sorry. This questions should better be addressed to the functional
programming gurus, however I will add my 10 cents too.

As in normal languages,
the first thing we could use in design should probably be an incapsulation,
or so called "abstract data types". Types, which are defined by the
operations
in them rather than their structure. For example, consider queue
implementation
from the standard library. It has not obvious (at least for imperative
programmer)
data structure, similar to Okasaki's queue (pair of two lists). Module queue
exposes queue constructor (new), and all of necessary operations (in, out,
etc).
#So we can create the queue
Queue = queue:new(),
#put in some elements
Q1 = queue:in( Element1, Queue ),
Q2 = queue:in( Element2, Q1 ),
#and pass it as a parameter
doSomething( Q2 ).

It's just fine, we succeed, we have a "class" queue defined now, with a
number of "methods".
But here is one problem remains.
Suppose we have defined another implementation of queue with a same
interface.
How would we define a generic function working with both implementation
then?
Problem is that we supposed not to have derect access to the data structure
of the abstract data type, so we need operations to be _polymorphic_.

An answer is that we should pass the module name ("class name") to this
function
in a some way...
Queue = anotherQueue:new(),
generic_function( anotherQueue, Queue ).
...and use it as a prefix for queue "methods" in function implementation.

To make it looking more "cool" (more close to the "classic" OO style) we
could include
module ID in data structure. Let's suppose that object in a top level is
always a tuple,
and the first element always contains the module name. Than we could invoke
"methods"
like this:

invoke( Object, Method, Params ) ->
	apply( getelement( 0, Object ), Method, [ Object | Params ] ).

I think you got an idea. I believe that people who have an experience of
development
in Erlang could suggest more effective and elegant approaches.

Vlad Balin