From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 23 Aug 92 22:14:28 GMT
	<PCG.92Aug16184526@aberdb.aber.ac.uk> <77947@ut-emx.uucp>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 18 Aug 92 15:10:50 GMT, hasan@ut-emx.uucp (David A. Hasan) said:

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

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.

pcg> Then, wouldn't it be better to adopt a 'reusable, orthogonal'
pcg> components for building a class rather than leaving bits of a
pcg> monolithic definition missing?

hasan> In particular, 1) is it the notion of an "abstract class" that
hasan> bothers you or is it the use of "inheritance" in any circumstance
hasan> (abstract class or not)?

It's really a bit of both. "inheritance" bothers me a lot because it is
commonly understood to be the equivalent of prefixing, i.e. a
hierarchical reuse mechanism that does not quite distinguish between
interface and implementation reuse. It is also a linguistic device with
pretences of data design semantics, hence the endless and pointless
debate as to whether inheritance models 'is-a' or 'has-a' or
'behaves-as-a' or 'is-represented-the-same-as-a" or other semantic or
pragmatic relationships.

Abstract classes bother me a bit because if they are just interface
reuse there should be a more appropriate mechanism, and if they are
there to provide partially complete assemblies of interface and
implementation components then I don't see a large reason to have them.

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

I'd be content enough with 'modules' probably. Really what is needed is
then a classification linguistic device.

One could simply provide a list of named interface and implementation (let's
for the moment ignore specifications, it's much the same) components,
and assemble complete classes from it.

But maybe it would be nicer to be able to assemble together components
without actually forming an instantiatable class, in order to provide:

hasan> To my eyes, the appealing aspect of "mix" of spec.  and
hasan> implementation mentioned by Ralph Johnson (above) is that it
hasan> allows for degrees of abstractness.

which is a quite good concern. But I am very much undecided about this.

Surely one certainly wants the facility to name not just single
interface and implementation components, but also groups of them; for
example an interface called 'stack' could be aseembled out of the
interfaces 'pop push top' and one called queue could be assembled out of
'append remove top bottom', and one called deque by merging them.

But I am not sure that it is a good idea to allow for mixed, but
incomplete, assemblies of both implementations and interfaces.

I have this feeling that classes, i.e. mixed assemblied, should be
complete, in the sense of being instantiatable.

In other words that the abstraction levels should be visible in separate
implementation and interface lattices, without having a lattice of
classes. In other words the relatedness of two classes should be not
directly specified, but indirectly, by looking the the relatedness of
the interface and implementation components that have been used to
assemble the one and the other.

The reason for which I have this feeling is that an algebra over classes
would be redundant with respect to the interface and implementation
algebras,  redundancy is often suspect.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk