Erlang hints from an CO junkie

Thomas Lindgren <>
Fri Aug 13 15:02:37 CEST 2004

--- Vlad Balin <> wrote:
> > Sorry, I'm afraid I don't follow you.
> Thats why you don't understand.

You don't say?

> Again, try to define function accepting an instance
> of
> abstract data type, (which, I remember you, is
> defined by the 
> set of operations _only_, you cannot directly access
> internals).

By a function "accepting an instance" of an ADT, I
take it you mean we have an element of the abstract
datatype which is passed as an argument to the

In that case, note that a function "accepting an
instance" of an abstract datatype does not necessarily
have anything to do with the ADT. (Other functions
will pass around ADT elements, for example.)

> And suppose you have 2 different implementation of
> the same
> ADT. There's no principal reasons not to do so, in
> other 
> case it's not quite 'abstract'. 


> You pass your ADT
> instances 
> as a parameter to this function.
> Since ADT is defined by the set of operations
> _only_, I would
> expect function to work properly for both instances,
> i. e. that 
> function will not notice the difference - operations
> are the same, 
> so type should be the same too!
> But it _will_ work properly _only_ in case, if
> operations will 
> be _associated_ with ADT instance.

Okay. The payoff, then.

But "associated" in _this_ case does not mean the same
as "methods associated with an object". An object has
*explicitly* associated methods, while in an ADT, the
data only has *implicitly* associated functions.

Reconsider my example of Smalltalk objects vs Erlang

> Look how ADT implemented in Haskell, as I can
> remember that
> is exactly such a case.

Haskell (or SML) is not the only way to implement
ADTs.  ADTs have been used in many programming

> In other case (if you refuse writing generic
> functions) this 
> question (are functions associated with instances or
> not) 
> is _academic_ and doesn't make sense at all, because
> in any 
> case you will not notice any effective difference
> between
> these two cases.

Of course there is an effective, practical difference.
I'll refer you to my previous example of writing an
Erlang tree ADT vs representing the tree as objects.
The design is different. The code is different.

> > Grady Booch told us an object has state, behaviour
> and
> > identity in 1991. This seems to be an accepted
> truth
> > in the OO community, as far as I can tell.
> Ok. I see. Open OCaml manual, OO section.
> Lets see did they accepted it or not.

OCaml is hardly the principal example of an object
oriented language.

> My impression is that 'object' is so general,
> popular and intuitive term 
> that the most developers I seen feeling free to use
> it without 
> consultation with Mr. Booch. :) So I would be very
> careful
> to talk about the community.

If you ask an OO practitioner what makes something an
'object', you might be surprised. (Hopefully not too
many will answer "huh?")

In closing, when I re-read this post, it appears I
have mainly referred back to points already made in my
previous message. So I'll leave it at that.


Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.

More information about the erlang-questions mailing list