From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object,comp.software-engineering
Subject: Re: Heresy discomfited!
Date: 14 Sep 92 15:56:29 GMT
	<PCG.92Sep12204548@aberdb.aber.ac.uk>
	<1992Sep13.201256.15754@neptune.inf.ethz.ch>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 13 Sep 92 20:12:56 GMT, santas@inf.ethz.ch (Philip Santas) said:

pcg> I will mention a dreaded paper, the Cardelli/Wegner survey on OO
pcg> (ACM Surveys December 1985), where they write:

    "In the context of this discussion it is useful to define
    object-oriented languages as extensions of procedure-oriented
    languages that support typed data abstractions with inheritance.
    Thus we say that a language is object oriented if and only if it
    satisfies the following requirements:

     * It supports objects that are data abstractions with an interface
       of named operations and a hidden local state.
     * Objects have an associated object type.
     * Types may inherit attributes from supertypes."

johnson> OOP has three distinguishing characteristics, in my opinion.
johnson> The first is the ability to define new data types, [ ... ]
johnson> The second is polymorphism by late-binding, [ ... ]
johnson> The third is inheritance, [ ... ]

pcg> but while you claim that your is a definition of OOP, they claim it is a
pcg> definition of an OOL, which seems to me rather more acceptable.

santas> From Programming Linguistics (D. Gelernter, S. Jagannathan. MIT
santas> Press, 1990) p. 249:

santas> The programming method induced by Simula, by Smalltalk, and by a
santas> large collection of subsequent languages inspired by these
santas> originals is called "object-oriented" programming.

Ah, I have no contention with this: I am the first to insist that OO is
essentially a casual byproduct of Simula I being generalized into Simula
67, and ideas from Simula 67 (object-as-closure, prefix chains of
closure templates) and Lisp (easy to parse syntax, latent typing) being
merged into Smalltalk in its various successive versions.

Indeed the seminal paper on OOP (Dahl & Hoare, "Hierarchical program
structures", in "Structured Programming", by Academic Press, 1973),
contains the following paragraphs:

	"A procedure which is capable of giving rise to block
	instances which survive it will be known as a _class_; and the
	instances will be kinown as _objects_ of that class. A class may
	be declared, with or without parameters, in exactly the same way
	as a procedure: [ ... ] Any variable or procedures declared
	local to the class body are called _attributes_ of that class;
	and so are the formal parameters, whether called by value or
	called by reference. [ ... ] The attributes of any object may
	be inspected or changed by the technique of _remote
	identification_. If _X_ is a reference variable qualified
	by the class _C_, and _A_ is an attribute identifier (i.e.
	local quantity) of that class, then _X.A_ refers to the
	attribute _A_ of the object cyrrently referenced by _X_."

which clearly describe the "classic" view of OOL (objects-as-closures,
and classes-as-closure-generators, also clearly illustrated in Abelson &
Sussman, "Structure and interpretation of computer programs"). In the
remainder of that fundamental, and little known, essay, the authors also
develop the shape of OOL design until CLOS.

But to be still thinking in terms of Simula 67 (prefixing that generates
hierarchical reuse structures, belief that OO programs are always
discrete simulations of the "real" world) is a catastrophe(wonderful).

It was my belief(delusion) that one by now could stand back and gain
insight into

santas> What I see here, is a definition based on prototypes.

If you mean "languages as practical examples of ideas", I agree; their
definition, just like Dahl & Hoare's twenty years ago, essentially
equates OOL as OOP.

Before Professor Johnson enlightened me I tended to regard this as quite
regrettable, and I tried to argue that it is more proper to subordinate
language design to an insight as to program decomposition (the
Parnas/Dijkstra way)

Instead of doing viceversa, like Professor Johnson authoritatively
states (actually he seems not to care one jota about insights into
program decomposition, as he explicitly rejected this point of view).

In my naive innocence I was also prepared to compromise, and put them on
an almost equal footing:

santas> They actually add:

santas> Object-oriented programming IMPLIES BOTH a general vision of
santas> what programs are AND A SET OF LANGUAGE CONSTRUCTS.

santas> (underlining is mine)

I could I agree completely (with one slight interpretative proviso
supplied later). So it is not entirely true that:

santas> This implies that each of the oponents in this thread, are
santas> HALF-correct (given the definitions above).

Not really; I was entirely and utterly wrong. Because while I
acknowledged the importance of language constructs, and I had spent a
lot of verbiage on trying to suggest that better language constructs
than prefixing/inheritance could be adopted, I was always naively and
mistakenly sure that they should be subordinated to an insight into the
decomposition paradigm they support.

Professor Johnson generously taught me that such concerns should be
completely dismissed, as they lead to unREAL OO programming.

Just for the sake of making full amend for my fast fallacies, I will
summarize them here again:

* OOP is entirely and completely defined as a program (de)construction
  philosophy based on a specific paradigm

* for best effect it must be supported directly by appropriate
  linguistic constructs.

* an OOL is any language that supports directly with language
  primitives the OOP decomposition paradigm.

* Prefixing, alias inheritance, is an unduly restrictive linguistic
  idiom that severely impedes full use of the OO decomposition
  paradigm.

* latent typing/dynamic overloading are important linguistic idioms
  especially suitable to programming-in-the-large, but are totally
  unrelated to OOP, as they don't directly support the OO decomposition
  paradigm.

So, while I insist(ed) that OOP is defined in terms of a decomposition
paradigm, I also remarked that effective direct linguistic support is
important to its application. Nothing could be more unREAL, I now
realize. And in my state of confusion I had dared write:

pcg> Surely you must be joking. You are making fun of us all with a
pcg> caricature of the thesis "OO *Programming* is really the same as
pcg> the features of the Smalltalk language, no more, no less". Down to
pcg> the detail that in some Smalltalk implementations objects "contain"
pcg> a class pointer/denoter.

santas> The same authors add the following (same page):

santas> The phrase "object-oriented" is supposed to mean "object-based"
santas> or "having to do with objects", "based on the use of objects".
santas> Perhaps after a hectic afternoon of phrasemaking, the excausted
santas> wordsmiths adjourned to a local movie theater to take in "LIFE
santas> WITH SMALLTALK-ORIENTED TOWARDS A TRUE STORY"

santas> (the underlining is mine)

And the humour is enjoyable by everybody.

santas> If the OO community and its practices are fixed, then there is
santas> no reason for research in it. But I still believ, that new
santas> languages can change the tradition,

Yes, as amply demonstrated by CLOS. CLOS has been as revolutionary for
our understanding of OOP as Simula 67 was in begetting it.

santas> and the "prototype-oriented" definition.

I used to think that insight, maybe, is more important and fundamental
than the languages and the features that generated it. Without insight
we are blind, and can only design languages by throwing in features
almost accidentally, and watch what happens (e.g. C++).

Objective C and in a stronger sense Eiffel are good examples of
languages that have been designed on the basis of a more or less
coherent set of insights, not as collections of features, and they are
to be appreciated for this, whether one agrees that those insights are
valid or not.

Both are still unsatisfactory in many ways; in particular both, and
especially Eiffel, may be criticized for being too slavishly modeled
after Simula 67 (down to reproducing some of the features it had only
because of certain implementation restrictions); but both have an
elegance with which other more hackish designs cannot compete.

Indeed, more research is needed as you say. OOPS. Sorry, I was still
thinking in my old heretical ways. There is no need of any more
research along certain thoroughly unREAL directions:

johnson> late-binding of procedure calls) is crucial in REAL oo systems.

johnson> Let me emphasize that it is quite likely Piercarlo is NOT doing
johnson> real oo programming.

-- 
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.object