Erlang hints from an CO junkie
Thu Aug 12 22:11:21 CEST 2004
> Wait a moment - in my last posting I did not talk about
> encapsulation at all.
To be correct - yes, in last posting you didn't. But I'm maintaining the
context of our discussion :) :
> Suppose we have a town with a thousand houses - suppose we say this
> is a static town (ie we decide that there will be no new houses, no
> houses will be changed) - this I'd model using a single town process.
> Now internally the town process might spawn off 1000 house process, it
> might stick everything into a big ets table or use a dictionary - who
> cares. The important bit is that the user only sees the protocol (ie
> the messages) between the application and the town process and not any
> internal details of *how* the town process is implemented.
The last sentense here about "important bit". That's about encapsulation.
What actually make our points of view different, is:
I suppose object = ADT instance (product of encapsulation).
For some reason you aren't share this point of view.
This is phylosophic quiestion.
> 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
Yes, in my terms - difference is that in one case you're using
"imperative" ADT, in other case "functionally clean", without side effects.
You suggested to perform high-level design in imperative style, taking
the natural consurrency in consideration. I understand what you saying,
just noted that there's much common with OO approach in terms of Alan key.
If not equivalent. Probably, if you will think of processes as the "large"
objects with state, processing "messages" it will greately simplify the
task of founding "concurrency patterns" you're talking about. Cause
an "objects" is conceptually the unit of concurrency according to Key.
Just look at it from another side.
> > Differens is only in terms. Your explanation implies that there's no
> > difference
> > between object and process.
Aha :) Remember - I suppose that "object" = "encapsulation unit".
I assume that encapsulation is an only relevant object's property.
Not too much to be actually pity about :)
> To illustrate the difference, you could provide
> > an example when 'concurrency pattern' is _not_ the unit of
> > but
> > you clearly stated that it always _is_.
> I don't understand this
Ok, forget it :) We're discussing the meaning of the terms here.
> 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.
Forced to agree,
you've found very bad and unnatural example to illustrate an essense of OO.
Smalltalk is such a language where everything is an object, yes.
It's not natural to send a message
to a string, right, but there's just no another way in Smalltalk to
the string. The language is conceptually simple (which is good), and
we just paying for this simplicity.
>From the other hand, string object from STL (C++) is an excellent example
of OO practice. Suppose you want to capitalize letters in the string. If you
going to find corresponding method in std::string, you are wrong. You
will not find it. Because string expose only an iterator interface, like
generic container, which doesn't depend on string implementation. _This_
is the right way to represent the string object.
What you have to do, is to apply _generic_ algorithm "transform" (working on
all container types!) and use scalar function toupper( char ).
Beutiful. Natural. Clever. And string is still an object.
[skipped the "ping-pong"]
> > 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.
> 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.
As I said, the main problem is that we're using different terminology. :)
But after "translation" it looks like we actually share opinion on main
Thanks a lot,
More information about the erlang-questions