🚀 go-pugleaf

In article <4398@well.UUCP> mitsu@well.UUCP (Mitsuharu Hadeishi) writes:
...
>	I would like to add, it is also because of the lack of object-
>oriented design of the libraries themselves.  When someone writes code
>that depends on the specific internal representation of an object, rather
>than its interface, it makes it difficult if not impossible to change those
>libraries or to improve their implementation.  

You've recognized the benefits of *data abstraction*.  By *specifying* an
abstract data type and the semantics of its operations (and requiring that
your clients know only this information), you effectively encapsulate the
internal data representation and the implementation of its associated
operations.  As a result, I (the implementor of the ADT) can change either
the internal representation or the operations in any way such that the
specification of the ADT holds (and *guarantee* that users of my ADT will
see no change in the new implementation, other than perhaps speed).

Back to the library problem.  The problem is not their lack of object-
orientedness (whatever that is :-), but that they are based on functions
instead of ADTs.  I contend that MODULA *modules*, CLU *clusters*, ADA (tm)
*packages*, etc. can be just as effective in accomplishing what you have
described.  Polymorphic functions, which are (partially) supported in only
one of the above, however, can be useful in building libraries (as noted
earlier in the discussion).  Math libraries, for example, (should) have
zillions of internal representations for matrices, and its nice to avoid the
'matmulhyper' syndrome required to multiply hypermatrices.

John Baugh (jwb@cive.ri.cmu.edu)
Carnegie Mellon University
-- 

%%%%%   John Baugh		Department of Civil Engineering   %%%%%
%%%%%   jwb@cive.ri.cmu.edu	Carnegie Mellon University        %%%%%