NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/object/4549

Internet Message Format | 1992-12-15 | 3.6 KB

Path: sparky!uunet!olivea!pagesat!spssig.spss.com!uchinews!alex!dave
From: [e-mail] (Dave Griffith)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Date: 15 Dec 92 20:12:42 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (News System)
Organization: University of Chicago
Lines: 67

In article <[e-mail]> [e-mail] (Ben Bongalon) writes:
>
>In article <[e-mail]>,
>[e-mail] (Dave Griffith) writes:
>
>|> Actually, immutability is only a small part of being a value.  The important
>|> part is lack of identity.  All '3's are the same, regardless of their
>history.
>|> On the other hand, standard objects are only equal if they are identical.
>|> Immutability is necessary for values, but not sufficient.
>
>Actually, it depends on how you look at it.  Are "all" 3's referring
>to several identical copies of that value or to one universally
>accessable value?  Not only is he latter a plausible answer but
>I believe it is a better model.
>

No problems here.

>Frankly I don't understand all the confusion about the distinction
>between objects and values.  As i see it, an object may have internal states;
>more specifically, an object may contain other objects, which
>may in turn be composite (ie, contain other objects) or simple
>(ie, just contains values).  But note that simple and composite
>objects are merely concepts in our minds.  In order to apply them
>to computer programming, we map these objects into variables.
>

The distinction between simple and compound is somewhat useful, but has
very little to do with the value/object distinction.  One may have simple
objects, with identity but with no internal state.  An example would be
capability tokens in operating system theory.  Atomic and immutable,
but also uncopyable, so that equality and assignment must be based on
identity.  OTOH, If we wish to have user defined values, compound values
certainly make sense.  Complex numbers (a compound of two real values),
and immutable strings (compound of some number of characters) leap to mind.

>The primitive objects are the
>variables in a program that are defined with primitive data types
>(ie, int i, float x, char c    <--- i,x & c are primitive objects).
>Composite objects are the variables in a program that are outside
>the set of primitive objects.
>
>An object can be ultimately decomposed into its primitive object
>constituents, and these primitive objects get _values_ assigned to them.

Far too limited and inflexible, as shown above.

>Thus, the disctinction between objects (variables) and values
>(literals) is clear.  Objects get values assigned to their data
>members.  Object X = Object Y  actually means that the values of
>the data members of Y get assigned to the corresponding data members
>of X.
>

Intriguing.  It seems as though your defining an object as something which
has aliasing semantics for assignment.  It is certainly the case, but it
seems a rather process-oriented and rarified starting point for defining
object orientation.  As though you were starting a discussion of lambda
calculus with formal reduction rules, without ever mentioning that your
formalism was meant to model something higher-level (mathematical functions).


--
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       [e-mail]
Oh, by the way, I almost forgot.  Godot called.  He said he'd be late.