From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 21 Aug 92 01:40:09 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.c
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 16 Aug 92 21:28:18 GMT, johnson@m.cs.uiuc.edu (Ralph Johnson) said:

johnson> Note that languages like Smalltalk have only implementation;
johnson> they don't provide a separate interface or specification.

Uhmmm. This is a matter for some disagreement. In Smalltalk there is
something that can be argued to be the interface definition, the
'protocol', that is the set of strings that identify the methods for a
class. The fact that in traditional Smalltalk arguments are not
decorated with type tags does not mean that there is no interface
definition part in a class; it is inextricably linked to the
implementation, which is one thing I am unhappy about, but it does exist
(and the browser extracts it from the class definition and makes it
plainly evident in the 'protocol' pane). Maybe I have not been clear
that interface to me is the syntactic phrase used to invoke a procedure
implementation, and that the name is part of that phrase. For example,
in '14 square' we have that 'square' is the interface to the squaring
method, whose definition, say 'square, ^self*self.' contains the
definition of both interface ('square') and implementation
('^self*self').

johnson> Only Eiffel provides any sort of specification (pre and post
johnson> conditions and class invariants) in the language.

Among object oriented languages I think you are right, but there have
been many old modular languages and some extensions of OO ones that
carry annotations and decorations like Eiffel. But I agree with the
point that they are rare.

johnson> Of course, in languages without separate interface
johnson> specifications, people use abstract classes to make a separate
johnson> entity in their program that is just interface.

johnson> The purpose of an abstract class is NOT supposed to be to
johnson> represent an interface.  An abstract class represents a
johnson> skeleton for a class.

So far you seem to be saying that an abstract class, to you, is just a
non instatiatable template for building other classes:

johnson> It is a class that is to be used ONLY by subclassing.  A
johnson> subclass designer creates a subclass by filling in the 'holes',
johnson> i.e. by "fleshing out" the skeleton.  It is true that C++

and Smalltalk, and all those that use a language that only allows
traditional inheritance.

johnson> programmers will create a class that is only interface, with no
johnson> implementation at all, but that is not the real purpose of an
johnson> abstract class.  An abstract class is implementation, not just
johnson> interface.

Often enough, yes.

johnson> An abstract class defines some "abstract" or "deferred" methods
johnson> whose interface is defined, but whose implementation is not.

So, at least in part, it does define reusable interface.

johnson> It also defines some "template" methods that are defined in
johnson> terms of the abstract methods.

Often enough, yes.

johnson> Subclasses must provide an implementation of each of the
johnson> abstract methods, and then they can use the template methods
johnson> that they inherit.  This is a very important and common design
johnson> technique in object-oriented systems.

I agree with you that code templates are quite useful, while noting that
this is true not just in OO languages, as there is nothing specially OO
about them.

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

Which is exactly about my point, incidentally. Why not separate
interface defining, generic defining, and class assembling into three
separate facilities? Then your 'abstract classes' would have no reason
to exist, and inheritance as well.

My argument is that conventional inheritance inextricably merges all
three notions in one inflexible hierarchical derivation mechanism, and
that this is quite bad, and that in part this sorry thing is enouraged
by thinking in terms of 'send a message to an object', as notated in
'O.M(...)'.
--
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