Erlang hints from an CO junkie
Thu Aug 12 22:47:40 CEST 2004
> > 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.
More information about the erlang-questions