NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/object/5116

Internet Message Format | 1993-01-28 | 9.7 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!agate!doc.ic.ac.uk!warwick!uknet!gdt!aber!aberfa!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: FAQ  Part 1 (of 2) [ identity and OO paradigm ]
Message-ID: <[e-mail]>
Date: 27 Jan 93 18:16:13 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET news service)
Organization: University College of Wales, Aberystwyth
Lines: 211
In-Reply-To: [e-mail]'s message of 22 Jan 93 00: 43:05 GMT
Nntp-Posting-Host: thor.dcs.aber.ac.uk

>>> On 22 Jan 93 00:43:05 GMT, [e-mail] (Bob Hathaway) said:

Hathaway> In article <[e-mail]>, [e-mail]
Hathaway> (Piercarlo Grandi) writes:

Hathaway> [On values and objects as procedural instances, across > 1 postings]

Hathaway> I haven't had time to look into these definitions in depth,
Hathaway> but there is a good point to be made here.  You can view
Hathaway> almost anything as anything else and can contort almost
Hathaway> anything into anything else if you try hard enough.

No, not quite -- you cannot contort a procedure into a label or an
object into a type definition. One can mask syntax, but the semantics
are either similar/equivalent or not.

Hathaway> Just because you can view objects in a strict functional or
Hathaway> procedural way

But I don't -- I am just *explaining* the fact that in all languages in
the Simula 67 mould (C++, Eiffel, Smalltalk, ...) objects are indeed
(persistent, usually) procedure instances and classes are the procedures
they are instances of. This is not at all a procedural or functional
view; it is the historically and practically correct view of mainstream
OO programming constructs.

Hathaway> Now comes the problem of deciding which of these views should
Hathaway> represent the canonical one.

This has been already decided by the designers of Simula 67 for us.

Hathaway> You give an example of a particular procedural view to
Hathaway> objects, although besides being the most unnatural approach I
Hathaway> could think of

Complain to Dahl & Nyjgaard and Strostrup and Meyer about that; they did
it like that, I am merely reporting the fact.

Hatahway> Further, the proposed procedural approach seems to be
Hathaway> the furthest from a natural approach I can see.  People think
Hathaway> of objects as having structure and behavior (and more
Hathaway> recursively, usually through inheritance) and this can be
Hathaway> directly supported with a natural OO model.

Well, a closure defines state (the variables bound in the closure,
usually called the attributes or members of the object) and behaviour
(the procedures bound in the closure, usually called the method or
member functions of the class). That's precisely the point.


Hathaway> Nothing stating that an object is an instance of its
Hathaway> constructor.

No, no, the constructor is the _body_ of the procedure/class, it is not
the procedure/class itself. So objects are instances of the
procedure/class, and their state is initialized by the body of the
procedure/class.

Hathaway> Smalltalk places the constructor in its metaclasses

The metaclasses are "just" the reflectively reified symbol table entries
that describe the procedure/class.

Hathaway> and C++ places them in classes as a special member; just one
Hathaway> among many.

Ah, in C++ the disguise of the procedure body as the constructor is most
transparent. Just two points:

* the constructor is kind-of a static member (per-class, not
  per-object) and is *untyped*.

* by explicit decision by Stroustrup, constructors are invoked
  with the same syntax as Simula 67 classes.

A literal equivalence:

  class complex {        CLASS complex;
    float re, im;          REAL re,im;
    complex(float re,im)      PROCEDURE init(i_re,i_im)
    : re(re), im(im) {}            REAL i_re,i_im;
  }                  BEGIN re := i_re; im := i_im; END
                BEGIN END;

  complex *i            REF (complex) i;
    = new complex(0.0,1.0);      i :- NEW complex; i.init(0.0,1.0);

The Simula 67 notation on the right is a bit opaque, just like the C++
notation on the left; once would rather write, more naturally:

  CLASS complex(re,im)
    REAL re,im;
  BEGIN END;

  REF complex i;
    i :- NEW complex(0.0,1.0);

Now, if you cannot see the substantial, relevant, equivalence of all
three versions, it's not my fault.

Hathaway> Your proposed procedural view is just so much further from the
Hathaway> truth.  If you want to implement your objects or even present
Hathaway> your proposed procedural view

A disclaimer here: this is not *my* _proposed_ view. This is how Dahl
and Hoare describe Simula 67, and how in fact all languages derived from
Simula 67 are; I have posted the relevant quote from their article (the
one that founded the whole subject of OO programming, and that so few
people seem to have read) some time ago. But instead of just quoting it,
it would be better to read the entire paper.

As to *my* views, I think, as I have remarked elsewhere, that the
"Hierarchical program Structures" paper is insufficient and actually I
quite disagree with its thrust, which is well summarized in its title.

Hathaway> You can change the meaning of value to be synonymous with
Hathaway> objects

I don't do this, this is indeed the *fact*, that objects are values. An
object is just, after all, a collection of bits, when looked at closely
enough, i.e. a number that encodes some information. Nothing more,
nothing less.

Hathaway> but I think this is confusing (I think you would use the term
Hathaway> "dangerous" here) because values are equal regardless of
Hathaway> identity

Why should values be always equal regardless of identity? Their
denotations/extensions may be equal, but their addresses need not be. I
can well have two cells that have as extension/denotation the number 3,
but they may have different addresses. In side-effect free languages
the address of values is not visible to the programmer, but this is
quite different from implying as you say that in non side effect free
languages identities do not arise.

Hathaway> and identities are always unique;

By definition :-).

Hatahway> there is an important distinction here in the object-oriented
Hatahway> model because *both* are present.

Actually values can be EQUAL without being EQ in virtually all non side
effect free languages, this has got nothing to do with OO.

Hatahway> (something which doesn't occur naturally in the functional
Hatahway> model your proposal is natural for),

Which proposal? I have advanced no proposal at all. That in non side
effect free languages EQ and EQUAL are different predicates and that
values with different addresses/identities may denote different
mathematical entities is not a proposal, it is a fact. I mentioned
functional languages only as the exception, as they are, as a rule, side
effect free.

Hathaway> I don't claim that object identity is exclusively
Hathaway> object-oriented, but that object-orientation includes object
Hathaway> identity.

This is a very curious claim; you seem to say that the one cannot do OO
programming in pure, side effect free languages. This is rather
astonishing, and will be news for a few people, who have been, in their
innocence, doing research on what they believed to be direct support for
the OO paradigm in pure/side effect free languages for quite a long
time. :-)

Hathaway> [ ... identity and value ... ].  Again, the distinction is so
Hathaway> important that it should not be possible to confuse the two,
Hathaway> let alone to consider them synonymous.

Who ever did this? As to me I was quite clear that a value/object may
have both an extension and an intension, the only exception being
pure/functional/side effect free languages (and HashCons Lisp) in which
the identity of a value is not visible, only its
contents/"value"/extension representation.


pcg> I also cannot find any way in which names are more loosely bound to the
pcg> objects they denote in Smalltalk or Lisp rather than in conventional
pcg> (algorithmic?) languages (like Eiffel or C++?).

Hathaway> Easy, names in Smalltalk can refer to any object (names are
Hathaway> loosely bound to the objects they denote), names in C++ that
Hathaway> are not references or pointers can only denote one object
Hathaway> (names are tightly bound to the objects they denote).

This is a very peculiar definition of loose/tight and use of the term
'binding'. Besides surely in C++ variables and other denoting entities
can refer to many objects. I think here you are confusing two distinct
concepts: whether a language is pointer based, and whether it is
weakly/latently typed.

Smalltalk happens to be pointer based (all objects must be accessed via
a pointer) *and* latently typed (a denoting entity can denote objects of
any type/class/mode); C++ happens not to be pointer based (denoting
entities can denote objects directly) and strongly/statically typed (a
denoting entity can only denote objects of a given type/mode/class).

I think that what you wrote is a slip, what you probably meant was (as I
think I have written in another of my multinefarious postings):

  Many OO languages are pointer (or "reference") based; in them
  a denoting entity can only denote a pointer to an object. Some
  aren't. Some OO languages also (often those that are pointer based,
  but not necessarily) are weakly/latently/dynamically typed, in that
  the type/mode/class of a value/object accessible thru a named or
  unnamed entity is not known until runtime; some other OO languages
  are strongly/statically typed, in that the type/mode/class of all
  values/objects that can be accessed via an entity is declared at
  compile time. Neither quality is essential for OO languages; indeed
  both qualities apply in their various combination to non OO languages.