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

Internet Message Format | 1992-12-17 | 4.8 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!olivea!inews.Intel.COM!tcad05!bongalon
From: [e-mail] (Ben Bongalon)
Newsgroups: comp.object
Subject: Re: Object hidden state and side effects
Message-ID: <[e-mail]>
Date: 17 Dec 92 20:13:21 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News System)
Reply-To: [e-mail] (Ben Bongalon)
Organization: Intel Corporation, Santa Clara, CA USA
Lines: 102
Nntp-Posting-Host: tcad05


I wrote:
|> >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.
|> >

Dave Griffith replied:
|> The distinction between simple and compound is somewhat useful, but has
|> very little to do with the value/object distinction.

My response:
   On the contrary, it does.
   I made the distiction between simple and compound objects to ultimately show
   the relationship between objects and values:  that is, values get
   assigned to data members of objects.  objects are not actually assigned
   to other objects-- it's the values of their data members that _should_
   get assigned to the corresponding data members of the lvalue object.

   The distinction between simple and compound objects allows one to see more
   clearly the recursive application of the object assignment rule.


Dave:
|> 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.

Me:
   Let's see: "Atomic and immutable, but also uncopyable" ...i agree

   "...so that equality and assignment must be based on identity."

   I agree with what i think you are trying to say but not on how
   you said it.  A capability token is uncopiable and therefore cannot
   be assigned-- it can only be referenced.  I think the problem lies
   in the overloaded meaning of "assignment".  Similarly, "equality"
   in this case really means "test for identity, or check of Object A
   and Object B are one and the same object".


Me again:
|> >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.
Dave:
|> Far too limited and inflexible, as shown above.

My response:
   sorry, my fault...i didn't go far enough.
   Primitive objects are objects that cannot be further broken down
   into other objects.  They are atomic because:
    a) They are directly mappable into the primitive data structures
       of a language.
       (ie, int i, float x, char c   <--- i,x & c are primitive objects).
  or
    b) They don't have any data members.
       (ie, your capability token example)

going back to your example, a capability token cannot be assigned
(ie, copied) because of the "assignment" definition:

  Object X = Object Y  means that the values of the data members of Y
    get assigned to the corresponding data members of X.

  So if Object Y (and similarly, Object X) have no data members,
  "assignment" is undefined.


Finally, Dave writes:
|> 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).

I think I'm just giving an alternative interpretation (one that works for me,
anyway) of the same concepts and notions about "identity" and "equally" that is
also being discussed in this newsgroup, ie:

   Obj A  is equal to Obj B    if   Obj A and Obj B are one and the same object

what I added is a methodology of mapping the concept of objects into the data
structures of a language.


Ben Bongalon
Intel Corporation