ADT's (was: Re: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si sugat))

[Chris Pressey]

On Thu, 29 May 2003 14:31:27 +0200 (MEST)
Bengt Kleberg <eleberg@REDACTED> wrote:

> 
> > Date: Wed, 28 May 2003 15:02:16 -0500
> > From: Chris Pressey <cpressey@REDACTED>
> > Subject: Re: COPL, the Tandem, PLITS and JAVA (WAS Re: Eppur si
> > sugat)
> ...deleted
> > badly, some research would have to be done into what means of
> > aggregating data & code have succeeded in not sucking.
> 
> abstract data types (adt).

ADT's are 90% of it.  Encapsulation, interface - the important things. 
But each stands alone - they don't co-operate.  That's the other 10%.

Inheritance?  Great when it's used wisely; almost never used wisely.
It can be avoided by implementing ADT's in terms of other ADT's.

Polymorphism?  Forget it - it's another case of making relationships
implicit - I'm against it on the same basis I'm against monads.  The
program is clearest when all relationships are made explicit.  When two
types really do share a common interface, I think it should probably be
a behaviour, cleanly seperated.

That leaves associations.  They're really more in the realm of
relational databases, but since most OO languages have shared state,
they were easy to dovetail in.  They wouldn't work the same in Erlang
unless all ADT's were stored in [ets|dets|mnesia] tables - almost
certainly a bad requirement!

But associations are too useful to ignore - they're what makes an object
model coherent IMO.  Having Employee and Company types tells you very
little - but knowing that a Company employs one or more Employees is
halfway to implementing it...

It's probably not as important to come up with a language mechanism, as
it is to cultivate some kind of discipline or tradition (like e.g.
Perl's approach to OO.)  There's no shortage of examples; what's lacking
is a comprehensive design pattern.

> bengt

-Chris