Erlang hints from an CO junkie
Thu Aug 12 14:39:31 CEST 2004
On Thu, 12 Aug 2004, Vlad Balin wrote:
>>> 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
>>> 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
> 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.
Wait a moment - in my last posting I did not talk about encapsulation at all.
In Erlang there are two ways to encapsulate things.
- hide the things in a process and access then through a defined
- hide the things in an abstract data type and access through function calls
again deciding which method to use is part of the design process
> Differens is only in terms. Your explanation implies that there's no
> between object and process.
To illustrate the difference, you could provide
> an example when 'concurrency pattern' is _not_ the unit of encapsulation,
> you clearly stated that it always _is_.
I don't understand this
>> 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
> 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?
Yes - data structure are passive, they just are. You can describe them
Functions are active they do things to data structures.
For a given data structure (say a string) there is a vast (unlimited?)
number of things you could do with it. Trying to isolate a small number
of these things and packing them into a "string object" seems silly to me.
Imagine a library. There are two types of books in a library
Dictionaries - which define what words mean
Non-dictionaries - which use the words in the dictionaries
Now suppose the words in the books were all objects. Now would we describe
the car object.
If we have to include car methods in the definition the definition of a car
would be enormous.
The car object would not only the definition
car: "tin box to transport people and things"
but would have to include all uses of car, in all the other books in
IMHO it's much better to have a data dictionary that defines all the
data structures to be used - these should be describe declaratively
Then there should be sets of functions that work on these data types.
> First, you just suggested to do so when using processes as encapsulation
> which are accessiblie via the defined protocol only, and implementation
> underlying data structures) is hidden. Sending message is almost equivalent
> calling a method.
No it's not.
Calling a method is synchronous - you suspend until you get a return value.
Sending a message is asynchronous, you send the message and continue.
> Second, you (I guess) consider using of Erlang behaviours as good practice.
> This is another example of abstract data types application.
Almost. Behaviours are a lot more than ADTs. ADTs should (IMHO) be
side-effect free, referentially transparent etc. Behaviours
encapsulate a lot more than just functional behaviour.
For example the OTP application behaviour could in no way be considered
A behaviour should capture "a behaviour" ie how the system behaves
when something happens, behaviours are usually chunk of generic code
which are parameterised with a number of callback functions. This is
very different to typical ADT type code.
> 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?
Of course not
>> In my way of thinking we can model things using the following
>> 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
>> 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
> 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
> objects(processes)', since they are not visible to the user of the City
> What you did? You created an abstraction for City, with implementation
> hidden; _this_ is called object, or 'abstract data type' instance, or
> whatever you
Well I don't use the word object.
To me a process is a statefull thing which has it's own thread of
control and which can communicate with other things by sending and
receiving messages it also has complex behaviour in the presence of
Then there are data structures and functions which act on data
structures these can be conveniently combined into modules to provide
abstract data types.
> P. S.: Our messages tends to be quite long, :) so I'm going to answer to the
> part later.
> Sincerely yours,
> Vlad Balin.
More information about the erlang-questions