NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3222

Text File | 1992-08-16 | 6.7 KB | 143 lines

Newsgroups: comp.object
Path: sparky!uunet!sun-barr!ames!ads.com!saturn!doug
From: [e-mail] (Doug Morgan)
Subject: Re: O.M() versus M(O) notation
In-Reply-To: [e-mail]'s message of 16 Aug 92 18:45:26 GMT
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
    960-7300
References: <[e-mail]>
    <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Date: Mon, 17 Aug 1992 04:00:24 GMT
Lines: 125

In article <[e-mail]> [e-mail] (Piercarlo Grandi) writes:

   ...

   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:

I think that proper terminology is rarely used because the underlying
ideas are shortchanged by the popular OO literature and folklore.  Of
the popular OO books I have looked through, I only remember Meyer's
OOSC as even hinting at the subject with any sort of internal
consistency and abstraction.  Even there, the depth was just enough to
introduce some basic ideas.  Lots of European texts on various formal
methods seem to be quite clear, but are not in what I see as the U.S.
mainstream of the OO culture.

   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.

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

Your personal usage of "type" is better than "type denotation."  If an
adjective is ever needed it should probably be more like "denoted
type" or "type denoted by such and such notation."  This more clearly
carries the meaning that the symbols of the specification denote
objects (mathematical, of course) of some type.  I would extend this
to say that at any one time an instance of a class should also denote
some type.  That is, with the proper context instances and
specification should both denote the same abstract types.  (A running
system as mutating specification?)

As an aside, several different denotation functions can apply to one
class instance.  The denotation mentioned above maps instance to type
(a.k.a. state or value).  Another denotation maps to the block of
memory (and perhaps procedures) associated with the instance.  This
computer implementation oriented denotation allows systems to
manipulate instance structures for standard inheritance, memory
allocation, I/O, DB, inspection, etc.  My impression is that the
second denotation so dominates the U.S. OO community (being dominated
by C++, it seems) that suggested improvement to OO techniques (e.g.,
pcg's) will only work their way into completely new languages or
offshoots of low volume languages.

   ...

   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.

This issue may finally boil down to genetic predispositions and
environment influences.  Some people just see M(O1,O2,...) as fitting
so beautifully into their notions of mathematics, symmetry, Occam's
razor, etc.  that no other notation makes an iota of sense.  Others
just see O1.M(O2,...) as the high point of the new OO-think of
encapsulation, message passing, classes, etc.  Neither group accepts
the the other's view and compromise is out of the question.  (Oh, by
the way, the TRUTH is that the first group is completely correct and
the second is completely misguided.)

...[My summary of a block of text: separation of
interface/implementation/specification is good but not done in today's
OO languages]...

I think the goal is wonderful.  A few questions:

O Do you have or know of any proposals for a system implementing this
  principle?
O How would this new system handle the fact (?) that specifications
  are most often handled off-line on paper or in someone's head?  How
  would it deal with specifications it can't really "understand" well
  enough to transform to appropriate machine code.  For instance, I
  would like to add "finite" to set to get finite-set (or remove
  finite from finite-set to get just set).  How would this work into
  the ways of combining specifications?  As you say, doing
  specifications right is HARD.  And even if you do them right,
  today's compilers and systems wouldn't be able use them.
O An example?  How about seeing how the new system would address a
  question that pops up on this group every month or two.  The
  question is always how to organize the inheritance of a mutable
  square class instance with three slots and a mutable rectangle class
  instance with four slots.  Now, how would this new system help
  clarify the notions of abstract types (rectangle and square), class
  instances denoting specific types, and different constraints on the
  mutation of instances?
O Could the system simultaneously and cleanly treat class instances
  themselves (if there are such things as classes and instances) as an
  interesting abstract type?  I think this second denotation
  (mentioned above) is needed to solve many efficiency, meta-class,
  and OODB-type problems.

   --
   Piercarlo Grandi                   | JNET: [e-mail]
   Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
   Penglais, Aberystwyth SY23 3BZ, UK | INET: [e-mail]

doug
--------------------------------------------------------------------
Doug Morgan, [e-mail], [phone]
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------