From: santas@inf.ethz.ch (Philip Santas)
Subject: Inheritance (was: Re: O.M() versus M(O) notation )
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Tue, 18 Aug 1992 22:23:16 GMT


In article <PCG.92Aug18145434@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 17 Aug 92 22:26:21 GMT, santas@inf.ethz.ch (Philip Santas) said:
>
>santas> Concerning specification: I think that subclasses should inherit
>santas> it as a whole, otherwise there is no point for making a class
>santas> subclass of another.
>
>Maybe, but probably you are still thinking in terms of inheritance, as
>your use of the seven letter verb indicates. There is no reason to
>believe that if one has a general algebra over interfaces specifications
>and implementations, derivation need only happen by subsetting. For
>example one could derive a more general class from a less general one,
>usually by adding (or substituting) interface and implementation
>components, and the specification of the resulting class might well be
>weaker.

This is still part of my inheritance, since you speak of sub-specifications.
I do not see you doing something different: if one brakes the whole thing into
pieces you can apply exactly these mechanisms to its parts. 

>For example, once one has written interface and specification and
>implementation components for fixed length queues, one might want to
>reuse (be it ever praised!) them, or parts of them, to build a
>dynamically resizable queue class. In this case the derived
>specification will not have the assertion that 'items <= maxitems'.

Oh, if they are _fixed_length queues, then the last is 'items = maxitems'.
Anyway I get your point, but you still have a form of indexing the parts
of a specification and you pick-up or remove indexes from a collection of them.
What is so strange about it?

>santas> The problem with interface is that current OOPLs do not use
>santas> functors for classes, ie. functions which construct new classes
>santas> out of older ones.
>
>On this we are thoroughly agreed, actually it is my main point. It is
>this that I have in mind when I say that languages should have notation
>to cover full general algebras over interfaces, implementations,
>specifications; those 'functors' of yours are the operators of such
>algebras.

And this already requires Classes and Types being first class objects.

>Even if most current languages do have some 'functors' over 'types',
>i.e.  type constructors, e.g. 'array', 'struct', 'pointer to', 'union',
>etc., as most current OO languages do have some 'functors' over
>'classes', e.g. the ':' of C++, or 'inherits' of Eiffel.
>But yes, they lack the necessary flexibility and generality.

Languages should allow the user to define its own functors.
It is really sad to read articles that this is metaprogramming (sic), and the rest,
when this is actually what programming should be about. After all, what some
consider as values in one system, can be types/classes in another.

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
     



Newsgroups: comp.object