From: hasan@ut-emx.uucp (David A. Hasan)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 18 Aug 92 15:10:50 GMT
Organization: UTexas Center for Space Research

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>Let me now give some contrived example:
>
>type:
>	``fixed size deques'' (cannot do much better than this :->)
>specification:
>	... contents:: fsequence where capacity = limit ...
>	... push x :: card contents < limit -> x ++ contents ...
>	... append x :: card contents < limit -> contents ++ x ...
>implementation:
>	...
>	push(self,item)
>	{
>	... if (diff_ring(self->top,self->bottom,self->slots) > 0)
>	  self->ring[anticlockwise(&self->bottom,self->slots)] = item; ...
>	}
>       [...]
>interface:
>	... template<T> void push(deque<T> &,const T); ...
>	... template<T> void append(deque<T> &,const T); ... 


For those of us "lurking" on this discussion who are not
particularly versed or brave enough to contribute to the 
specifics, let me THANK you for this example.  It immediately
illuminates quite clearly exactly what you intend when you
use the terms "type", "spec.", "implementation" and
"interface". 

 
>And here we are at one of the crucial points of this discussion. The
>title of this thread is "O.M() versus M(O) notation", and my thesis has
>been that:
>     it makes a lot of difference which notation is used to describe
>     operations on a value
>because the notation strongly influences thought processes and actually
>constrains them (cfr. Dijkstra on BASIC), and that in particular the
>'O.M(...)' notation by making 'O' visually special suggests that
>overloading should happen only on the first argument, which is most
>probably a misleading impression, as overloading resolution ought to be
>symmetrical, which is the most "natural" thing.
>
>Given this thesis, fuzzy use of the word 'type' is quite a disaster.


Well, I must say that I HAD lost track of your original point.
This review was very useful.


>johnson> An abstract class is much more than just an interface
>johnson> specification.  It also includes part of the implementation of
>johnson> the class, but it has some 'holes' in it that subclasses must
>johnson> fill in.  It is really a reusable design for subclasses, not an
>johnson> interface specification.
>
>Then, wouldn't it be better to adopt a 'reusable, orthogonal' components
>for building a class rather than leaving bits of a monolithic definition
>missing?


In view of the fact that you've helped me out by providing
the examples and summaries above, would you be so kind as to
elaborate on this point?  In particular, 
   1) is it the notion of an "abstract class" that bothers
      you or is it the use of "inheritance" in any
      circumstance (abstract class or not)?

   2) do you have alternative strategies in mind (e.g.,
      generics)?

To my eyes, the appealing aspect of "mix" of spec.
and implementation mentioned by Ralph Johnson (above) is that
it allows for degrees of abstractness.  That is, a designer
need not provide ONLY a completely abstract (or generic)
component, but may "partially instantiate" it for certain
(perhaps common) situations.  The advantage of this is that
subsequent use of the partially instantiated abstraction allows
the clients to concentrate on a subset of what would otherwise
be a large number of "holes" (generic actual parameters).

Do you have any thoughts on this?

-- 
 |   David A. Hasan
 |   hasan@emx.utexas.edu 
Newsgroups: comp.object