Erlang hints from an CO junkie

[Vlad Balin]

> > just one of the names for ADT functions. 
> 
> Not at all. One of the concrete differences between
> abstract data types and objects is that methods are
> associated with the object itself, while in an ADT
> they are not. (OO proponents often consider this is an
> advantage of OO.)
Not at all. :) See the next answer.
 
> > In some
> > terms
> > ADT interface functions are 'associated' with an
> > instance - 
> > yes, because in other case you will not be able to
> > define
> > generic function on it (it receives only the
> > _value_!). 
> > This is the main issue.
> 
> Sorry, I'm afraid I don't follow you.
Thats why you don't understand.

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

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.

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

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.

So from my side I don't understand where's the reason for
discussion on this topic.

> > Here is nothing said about identity and state in
> > definition.
> ... (big snip) ...
> > Yes, some _implementations_ may add more specific 
> > properties to objects such as state and identity,
> > but
> > terms 'class' and 'object' (class instance) has
> > became
> > quite common in whole context of OOP and can be 
> > hardly associated with a particular langugae now.
> 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.

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.