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

Text File | 1993-01-21 | 7.2 KB | 127 lines

Newsgroups: comp.object
Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!csus.edu!netcom.com!objsys
From: Bob Hathaway <[e-mail]>
Subject: Re: FAQ  Part 1 (of 2) [ identity and OO paradigm ]
Message-ID: <[e-mail]>
Sender: [e-mail] (Object Systems)
Organization: Object Systems
References: <[e-mail]> <[e-mail]>
Date: Fri, 22 Jan 1993 00:43:05 GMT
Lines: 115

[Scheduled system shutdowns here will interfere with my posting for a few
days; I was caught in the middle last night...]

In article <[e-mail]>, [e-mail] (Piercarlo Grandi) writes:
[On values and objects as procedural instances, across > 1 postings]

I haven't had time to look into these definitions in depth, but there is a
good point to be made here.  You can view almost anything as anything else
and can contort almost anything into anything else if you try hard enough.
All you need is computational completeness and most programming languages
and models have it.  Just because you can view objects in a strict functional
or procedural way doesn't mean you have too, they're just one alternative
among many.  Now comes the problem of deciding which of these views should
represent the canonical one.

  [BTW, another reference on modeling functional languages is "Compiling With
   Continuations", which I plan to read soon.]

You give an example of a particular procedural view to objects, although
besides being the most unnatural approach I could think of I see what
appear to be a few flaws (or difficulties) with them already.  One is that
there seems to be only one constructor.  Even C++ offers constructor
overloading, and virtual constructors (with what seems to be both parametric
(one-body) or ad-hoc (many-bodied from derived classes) solutions) are also
neeeded and I don't see how this fits in with the procedural approach.
Even for the simple overloading case, do you propose to duplicate everything
in the body of every constructor?  And some form of inheritance, as found
in natural object-oriented models [read non-procedural as you've proposed],
can handle the overriding case.  Further, the proposed procedural approach
seems to be the furthest from a natural approach I can see.  People think of
objects as having structure and behavior (and more recursively, usually through
inheritance) and this can be directly supported with a natural OO model.
Why contort this into a closure (or record with a function pointer and free
variable list)?  It *may* be possible, but quite unnaturally.

A more direct view of objects (at least in a class-based model) is with
structure and behavior, nothing funny.  Nothing stating that an object is
an instance of its constructor.  Smalltalk places the constructor in its
metaclasses and C++ places them in classes as a special member; just one
among many.  Some classes don't even have a constructor (although there
is a default), so to revolve everything around a constructor seems far-
fetched.  Revolving everything around objects (or even classes) in an object-
oriented model is natural, revolving them around procedures is not.  I claim
the procedural-oriented view is most appropriate for procedural languages
and not object-oriented ones.  If anyone is to argue, it should be the
single-hierarchy camp arguing that they are truly object-oriented (by
the literal transliteration), or certainly more oriented towards objects
than the class-based languages.  Your proposed procedural view is just so
much further from the truth.  If you want to implement your objects or even
present your proposed procedural view as an alternative which may provide
insights or usefulness under some circumstances, fine, its just not
appropriate for the canonical object-oriented view.  Actually,
continuations and closures are how many functional languages are
implemented, and may even be the canonical functional view for *those
languages*.  Right thing, wrong paradigm  [New category.  Or perhaps:
Wrong thing, right way?].

And for values, one can think of a value as having extension only, as in
relational databases.  Multi-valued dependencies can be said to only work
with values (extension), since any values that match are equal (no
intension).  You can change the meaning of value to be synonymous with
objects (or even model object-oriented models with a canonical functional
model), but I think this is confusing (I think you would use the term
"dangerous" here) because values are equal regardless of identity and
identities are always unique; there is an important distinction here
in the object-oriented model because *both* are present.  It is a grave
programming error to use the wrong kind equality (something which doesn't
occur naturally in the functional model your proposal is natural for), so
the distinction should be *crystal clear* in both construct and definition
in the object-oriented model.  [In other words your view is anachronistic,
or "out of place"]

[You were confused on a number of issues I brought up, perhaps I can be
more precise.]

I don't claim that object identity is exclusively object-oriented, but
that object-orientation includes object identity.  In the same way I don't
claim object-oriented languages lay claim to descriptor-based approaches
such as pointer semantics, but rather that object-oriented models are
often instances or subclasses of such approaches.  Just because object-
orientation uses object identity (and not vice-versa) doesn't justify using
a value-orientation model for identity and value, this is non-sequitur.
Again, the distinction is so important that it should not be possible to
confuse the two, let alone to consider them synonymous.  This reminds
me of the = and == operator (assignment and equality) problem in C, where
nasty errors can occur because of the orthogonality of the operators.
I would not want to see the same problem arising in OO languages because
objects were considered "values", where value is usually just one case of
value and identity.  Again, this is not the case in the functional model
where this seems to have come from.

>objsys> But then to the programmer, no.  These languages are symbolic,
>objsys> meaning that names are loosely bound to the objects they denote,
>objsys> unlike in conventional languages.
>
>This is one of the most bizarre definitions of "symbolic" that I have
>ever seen; I have usually "symbolic language" refer to languages that

I was quoting Coplien, someone you disagree with.  Since there is
dissension over the definition (and you have elaborated on a rather
classical one) of which I was not aware, I'll loose (or maybe change) the
passage from the FAQ.

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

Easy, names in Smalltalk can refer to any object (names are loosely bound to
the objects they denote), names in C++ that are not references or pointers
can only denote one object (names are tightly bound to the objects they
denote).  They are not polymorphic in the parametric typing sense and they
will never refer to any other object (intension) during the same lifetime.

bob
[e-mail]