Erlang hints from an CO junkie

[Vlad Balin]

> > 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
> function?
Yes.
 
> 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.)

Sure I know it's not necessary. :) I think you understand that
I assume it _will_ be used in this function for the purpose of
illustration.
 
> 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.

I see you agreed that operations are in a some sense
*associated* with an ADT instance. Good.

> Reconsider my example of Smalltalk objects vs Erlang
> terms.
Hmm... Interesting. Did it and still don't understand the
difference.

ADT is [explicitly] *defined* by the functions (operations 
on the type), how it can be done in implicit way? Please, 
illustrate it on queue from the Erlang standard library. 
The more examples the better.

> > 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
> languages.
I know. :)

> > 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.

> lookup({node, K, V, Left, Right}) -> ...
> lookup(leaf) -> ...

No effective differences from ADT point of view.
You will perform lookup for tree ADT like this:
lookup( Tree )

In C++ it will look like
Tree.lookup()
where Tree will be accepted as implicit parameter.
>From ADT interface and properties point of view - difference
is only in notation.

An _implementation_ and _design_ differences caused only
by the fact, that in conventional OO languages functions
can be polimorphic only by the type granularity. I. e. 
functions can be polimorphic in run time only by the one implicit
argument and only the difference in type is taken into account.
This fact force developers to introduce more "objects", than
in Erlang.

In contrast, Erlang has more powerful polimorphism is some sense,
allowing us to take values and structure of the data in cosideration.
However, there's no problem to define exactly the same 
ADT in C++ with a same design, but it will be not natural for C++
and less effective than using 'native' ideoms.

Again, from ADT point of view your example shows no difference.
Difference in only in the polymorphism model, leading to the
different code look and feel.

> > > 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.
Authors of the OCaml however think that it supports OO.
It conforms known OOP definition, and Mr. Booch agree
with this definition :). What else do we need? I don't think
it's better or worse than other OO language for our purpose
(proofing that OO community accepted Booch object definition
as a truth).

> > 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?")
Only in this mailing lists there are several different answers.
Btw, I see you are surprised by my opinion on that topic, huh? :)

Sincerely,
Vlad Balin