From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 23 Aug 92 21:53:41 GMT
	<PCG.92Aug12205741@aberdb.aber.ac.uk> 	<__5mtrq.objsys@netcom.com>
	<PCG.92Aug14170701@aberdb.aber.ac.uk>
	<1992Aug15.124149.28538@m.cs.uiuc.edu>
	<PCG.92Aug16184526@aberdb.aber.ac.uk> 	<1992Aug16.212818.29943@m.
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 21 Aug 92 02:55:30 GMT, johnson@m.cs.uiuc.edu (Ralph Johnson) said:

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

pcg> So, here you seem to be saying that abstract classes in most OO
pcg> languages are a considerable mess, because they *ought* to be used
pcg> as a poor man's template facility, and then end up being used as a
pcg> poor man's interface definition facility too.

johnson> No, that is not what I am saying.  They are a good template
johnson> facility.  They are all the template facility that Smalltalk
johnson> needs.  C++ needs "templates" in addition to abstract classes,
johnson> so they are perhaps not as good for languages with static type
johnson> checking.

Actually I reckon that both the Smalltalk way and the C++ way of doing
polymorphism (procedure implementations that can be applied to values of
multiple 'types', as long as these 'types' have some interface in
common) are fairly poor.

C++'s is bad because it is an ad hoc, static mechanism, that is really a
veil for macro processing. Smalltalk's because it does not make obvious
what is the interface that a polymorphic implementation requires, except
by inspecting the body of the implementation.

johnson> Lots of people, including me, have argued for a long time that
johnson> interface defining and class assembling should be separate
johnson> facilities.

Wonderful, but:

johnson> I call the relationship between interfaces subtyping, and the
johnson> relationship between classes subclassing.

More aggravating notation/terminology! Interfaces are parts of classes,
unless you mean that sublassing is really only about the implementation.
Or else it's hard to express the notion that implementations only are
being reused.

And, more importantly, WHY, why use 'SUBclassing SUBtyping' to indicate
relationships that can have nothing of subsetting, but actually be
supersetting or mixed? Even 'derivation' has an excessively hierarchical
connotation. I'd rather use 'interface reuse' and 'implementation
reuse', separately, and maybe reserve 'class reuse' to indicate that
both are meant at the same time, just as a 'class' should be built by
assembling interface and implementation (and specification) components.

johnson> You are not going to get rid of inheritance, you are just going
johnson> to call it by a different name.

Ah, yes, I'd call it 'hierarchical combined interface and implementation
reuse'. The big problem is that the notion of 'independent reuse of
interface, implementation, specification components' cannot be called
'inheritance', because it is more general. What about, an idea of the
moment, calling it simply 'reuse'?

johnson> Abstract classes are more powerful than templates because you
johnson> can do more than just fill in the missing operations, you can
johnson> also redefine the operations that are provided.

You are probably thinking of C++ and Ada here, and I agree. But if one
has general algebras over interface and implementation components,
'templates' (uninstantiatable assemblies of components) become more
general than abstract classes, as *everything* can be redefined.
--
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
Newsgroups: comp.object,comp.lang.clos