From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Tue, 18 Aug 92 03:23:46 GMT
Organization: Object Systems

In article <PCG.92Aug16184526@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:
>But professional mathematicians *know* that algebraic structures are not
>quite the same thing as their descriptions, and they can also *rely* on
>other mathematicians to know that as well.

IMVHO you're emphasizing the wrong domain since comp.object is mostly
computer science and software engineering oriented and more specifically
has to do with OO design and analysis, OO programming languages and their
implementation (compilers), and etc.

>And he also uses the same word for the specification of the semantics of
>those objects. To me, it is quite hard to follow. I really cannot
>imagine why it is so difficult to qualify 'type' with the proper
>adjective at least every now and then, for example:

Because type is already so well defined in the CS circles.  Again,
read up on the aforementioned references if you have any question on
the subject.  The term has been clear for a long time; some just confuse
it with implementation.  You even confuse it with real-world entities!

>type denotation:        the algebraic structure;
>
>type specification:     a description of the 'type denotation' using
>                        some suitable formal notation;
>
>type implementation:    an intension of the functions in a 'type
>                        denotation' expressed in some particular
>                        notation.
>
>type interface:         a way used to define/invoke the elements of the
>                        'type implementation' in some particular
>                        notation.

Wonderful terminology.  It is completely made up, but it is still wonderful.
Please use the existing terminology where it already exists.  Believe me,
I have been tempted to abandon the existing terminology myself from time to
time but it is not a good idea.

Try:
	some actual or abstract entity

     type              Describes the required attributes/properties/etc. of
                       an entity

     Implementation/Class  Describes an object; its visible attributes/
		       properties/etc. and sometimes its private parts.
		       Classes in "classical" OO languages.

     Methods/Components  Separate parts and definitions of an implementation.
		       Often in a "body" or file implementing the undefined
		       attributes/properties/etc. of an Implementation (or
		       Class) and its private parts.
		       Can even contain the private part of an object if
		       it isn't specified in the implementation (or class)
		       construct.

Notice people already know these terms.  Types are used for typechecking
and classes are what everyone expects.  Even abstract classes make sense now
and we all know what methods are.  I didn't make up any of these definitions
since they are quite standard and in use today.  The only point of confusion
may be that class and type are often combined and perhaps that the class spec
and class body division is seen to be of a little less importance than before
because of this division.

>I would personally use 'type' alone for the 'type denotation', and use
>'specification', 'interface' and 'implementation' on their own with the
>obvious sense.

But if you used the standard terms that everyone else in OO programming has
been using for years then you'll be able to communicate (and read) better.

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

Where's the type name and lexical scope of the construct?

>implementation:
>        ...
>        push(self,item)
>        {
>        ... if (diff_ring(self->top,self->bottom,self->slots) > 0)
>          self->ring[anticlockwise(&self->bottom,self->slots)] = item; ...
>        }
>        append(self,item)
>        {
>        ... if (diff_ring(self->top,self->bottom,self->slots) > 0)
>          self->ring[clockwise(&self->top,self->slots)] = item; ...
>        }
>        ...

Where's the context?  Do I have to look at the code and see if I'm going to
reuse these components?  I could see passing all referenced objects as
parameters to avoid new constructs, but you're unclear here.

>interface:
>        ... template<T> void push(deque<T> &,const T); ...
>        ... template<T> void append(deque<T> &,const T); ... 

Have you seen type inferencing or type variables?  And again where's the
name and lexical scope of the construct?

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

No it is not.  There is nothing symmetrical about pushing an element onto
a stack since the two objects are not equal gramatically.  O.M ...
is imperative (with an IE,) showing clearly the Object (O) to be the
receiver (or doer) of the command (M) and parameters to be objects.
A stack has a push "action" so the stack is the doer of the action and
making this explicit should help.  If this isn't so clear, then go
imperative without an explicit receiver of M.  If it is, you're obfuscating
the reciever which will be to the detriment of understanding.  Also, whats
with this "only overloading on the first parameter" stuff?  Have you
heard of multi-methods or more simply "dynamic method selection"?  I can't
make sense of it.

>Given this thesis, fuzzy use of the word 'type' is quite a disaster.

It is not fuzzy so please accept the well-accepted (by modern standards)
programming language definition.  If it wasn't defined clearly enough before,
it is now!

>I tend to think the former results in cleaner, less misleading notation,
>and greater generality. As a rule, those notations in which the
>primitive construct is a monolithic interface/implementation/specification
>definition idiom tend to have bizarre rules and restrictions on how the
>idiom can be subsetted and how subset definitions can be merged.

Yes, you do advocate reuse of interface which is better than not at all,
although apparently in mathematical terms: set operations instead of
traditional inheritance.  But people's natural thought processes are often
in terms of an is-a relation, not set operations.
	 [I'm glad you agree this is important, however.]

>In the case of some languages, like Smalltalk, some of the subsetting
>must be manually implemented by the programmer, in fairly inappropriate
>ways.

IMHO again this is not in harmony with the way people solve problems or
understand the world if you're arguing against simple inheritance.

bob
objsys@netcom.com

P.S.  After reading my last posting (after which I was quite tired, it
  was getting late), I noticed I had goofed *alittle* on one point with
  non-hierarchical classification.  Everything is still quite valid, but
  did you catch it?-)  Piercarlo?  Anyone???
Newsgroups: comp.object,comp.lang.clos