🚀 go-pugleaf

>>> On 7 Nov 1995 00:26:01 GMT,
>>> mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Matthew
>>> B. Kennel) said:

pcg> [ ... inheritance can be obviated by partial naming of members
pcg> ... ]

Matthew> Is this always so? 

pcg> No, it depends on how you define inheritance. But it covers the most
pcg> common definitions of inheritance (nee` prefixing), both single and
pcg> multiple, and so on (is-a, has-a, more or less).

Matthew> OK.  However, I think doing this would needlessly limit
Matthew> 'inheritance'; already Eiffel and Sather need something more.

Ok, OK, but I was talking about inheritance in its most common meaning;
if we want

pcg> The problem is that "inheritance" has become a good-for-all term for all
pcg> sorts of reuse. This is no good: reuse of interface is one thing, reuse
pcg> of implementation is another, hierarchical reuse is not the same as
pcg> piecemeal reuse, genericity is not the same as "inclusion polymorphism".

Matthew> Yes indeed.  Sather people don't like to use the term
Matthew> "inheritance" among ourselves.  The language has

Matthew> *  subtyping: [ ... interface reuse ... ]
Matthew> *  implementation inclusion: [ ... implementation reuse ... ]

Ok, and this happens at time also in non-strictly-OO languages, arguably
Modula-3. In the past years I have argued long and vocally that
inheritance-as-prefixing is a bankrupt concept, because one really wants
independent, flexible algebras for reusing interface, implementaiton and
specification. Sather and Modula-3 go some way towards it.

Now my line against inheritance-as-commonly known, I use _both_
arguments: that as-it-is (that is, with "normal" semantics") it can be
easily subsumed into composition, the particular point I was making this
time, and then that it should not be as-it-is, but that something far
more flexible is better. This is the same as your point, except for two
differences: that I would go much farther than you were hinting at by
pointing to Sather&C., and that I would no longer then call it
inheritance. It seems now to me that we are broadly in agreement as to
this. Incidentally, I find the Sather's "subtyping" and "implementation
inclusion" pretty ugly terminology, as a matter of taste. I also think
that one should have specification reuse too, where one can reuse the
predicates independently of the interface and implementation of a member
of a class, and so on.

pcg> But then consider the beauty of "any unique subset": if there is
pcg> conflict or ambiguity one can always resolve it by specifying a fuller,
pcg> less ambiguous name.

Matthew> OK.  But what happens when "what is a unique subset" in the code
Matthew> of one implementation is no longer unique when it is combined with
Matthew> additional code?

Matthew> Eiffel and Sather have renaming rules upon implementation inclusion
Matthew> for this reason.
Matthew> along with that object". 

Matthew> Personally I would like something with a little more individual
Matthew> control (e.g. Eiffel and Sather) which might let you pick and
Matthew> choose just what things you want to keep and the ones you want
Matthew> to junk.

Yeah, exactly my long standing point. Let me see, do I have here any old
article? Well, let's have a look: yeah, found some of them; I have
from these ancient scrolls of great truth :-) the less important bits:

  From pcg@cs.aber.ac.uk Sat Dec  8 21:00:11 1990
  From: pcg@cs.aber.ac.uk (Piercarlo Grandi)
  Newsgroups: comp.object
  Subject: Re: Examples of Multiple Inheritance?
  Date: 6 Dec 90 16:04:40 GMT
  In-reply-to: stt@inmet.inmet.com's message of 3 Dec 90 20:05:00 GMT

  [ ... ]

  We also need that the notation be a bit supported by the environment,
  and without crazy limitations (consider the difficulty one has in Ada
  to
  provide and let the user choose different bodies for the same package
  spec, and the _impossibility_ to do viceversa).

  [ ... ]

  From pcg@aber.ac.uk Thu Aug 13 13:16:43 1992
  Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  From: pcg@aber.ac.uk (Piercarlo Grandi)
  Subject: Re: O.M() versus M(O) notation
  Date: Wed, 12 Aug 1992 20:57:41 GMT

  [ ... ]

  The tragedy with inheritance is that it is unsually constraining. It
  forces unnatural kludges, as above, to do things that should be entirely
  obvious. Program modules can be described independently in one of three
  dimensions, the implementation, the specification, the interface. Now In
  theory programming should be done like this:

	  The problem domain is surveyed; data design is done, algorithm
	  design is done. Interfaces are defined, implementations are
	  coded.  Identification of structural reuse opportunities
	  are identified in all three domains.

  There is absolutely no reason to believe that structural reuse
  opportunities need to happen in a hierarchical fashion like with
  inheritance. Once wants the ability (my favourite peeve) to
  independently reuse interfaces, specifications, and implementations, and
  a general purpose algebra for all of thse things.

  For example:

  * given a deque interface, derive stack and queue interfaces by
  _subtracting_ the appropriate elements;

  * given two deque implementations, one with lists and the other with
  resizable arrays, attach one to a stack interface, and one to a queue
  interface;

  * given a specification of a variable size deque, derive from it a fixed
  size deque specification by adding the specification of a size
  constraint;

  and so on. It is clear that IS-A/HAS-A and other inheritance based
  relationships really don't provide a sound conceptual basis for all the
  work above, both because they are too hierarchical and because their
  level is often not clear (interface, implementation or specification?);
  for example IS-A/HAS-A usually are meaningfully applied only in the
  domain of specification, and really don't work in the interface or
  specification domains.

  [ ... ]

  From pcg@aber.ac.uk Sun Aug 16 18:45:26 1992
  From: pcg@aber.ac.uk (Piercarlo Grandi)
  Message-ID: <PCG.92Aug16184526@aberdb.aber.ac.uk>
  Date: 16 Aug 92 18:45:26 GMT
  In-reply-to: johnson@m.cs.uiuc.edu's message of 15 Aug 92 12:41:49 GMT
  Subject: Re: O.M() versus M(O) notation
  Reply-to: pcg@aber.ac.uk (Piercarlo Grandi)

  [ ... ]

  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:

  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.

  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; ...
	  }
	  append(self,item)
	  {
	  ... if (diff_ring(self->top,self->bottom,self->slots) > 0)
	    self->ring[clockwise(&self->top,self->slots)] = item; ...
	  }
	  ...

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

  (please forgive mistakes and imprecisions :->).


  [ ... ]

  From pcg@aber.ac.uk Tue Aug 18 17:29:27 1992
  Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
  From: pcg@aber.ac.uk (Piercarlo Grandi)
  Subject: Re: O.M() versus M(O) notation
  Date: Tue, 18 Aug 1992 13:57:25 GMT

  (Graham Matthews) said:

  graham> Could someone provide a concrete example of where seperating
  graham> interface and implementation buys one a whole lot,

  It's not really about 'buying you a whole lot'; it's that it's
  *necessary*, and either it has to be done "properly", or by perverting
  language facilities to other ends designed.

  graham> or where you want to inherit part of an interface.
			       ^^^^^^^
  The seven letter word! :-) Don't use that, it's misleading.

  graham> I am not saying that it can't be done or isn't useful, I am
  graham> merely interested in an illustrative example.

  Well, my favourite example has already been given: deque, stack and
  queue.

  One can design a general set of components with which one can build a
  deque, and then derive queues and stacks from deque.

  For example, one possible interface/protocol/signature/... of deque
  might be:

	  top, bottom	(return the values at one of the two ends)
	  push, pop	(operate on the top)
	  append, detach	(operate on the bottom)

  then that of stack might be:

	  deque EXCEPT bottom,append,detach

  The same for implementation and specification

  Everybody will have noticed that the reverse might be done too; one
  builds stack and queue components and merges them to get a deque.

  This is however bound to be less useful; it is only by "chance" that
  independently designed stack and queue components will fit nicely
  together. It usually pays to design the most general 'type' and then
  subset it, or enrich it with quite different properties. It then pays to
  have symbolic reduction engines as compilers (Turchin's REFAL
  supercompiler, many other previous/later ones), as these can efficiently
  specialize implementations.

  But this looks all pie-in-the-sky! Most languages don't even have
  partial application to specialize functions, not to mention
  continuations.

  Other simple examples that spring to mind are graph/tree, various
  varieties of indexing systems (various types of b-trees, of static
  indexes, of hashes), various multiple precision number systems, etc.

  In general there are many cases where arbitrary algebras on interfaces,
  implementations and specifications are useful, and typically:

  TOP DOWN
    when there are several denoted type/type denotations that are
    related; mathematicians have the habit, just like programmers, to
    develop algebraic structures by deformation of existing ones.

  BOTTOM UP
    when there are complex systems tend to develop over time like
    algebraic structures, by deformation of existing ones; requirements
    change a bit, implementations get extended or rewritten piecemeal, ...

  In neither case the deformation is likely to be hierarchical, as some
  participant in this discussion would have us believe; the keyword, let
  me say, is 'extended subset'. Mix and match, in all the three dimensions
  of interface, specification, implementation, seems to be the rule rather
  than exception. But maybe, as somebody has remarked, I am not doing
  *REAL* OO systems.

  [ ... ]