🚀 go-pugleaf

In article <1357@pivot-sts.sbi.com>, linke@sbi.sbi.com (User - Bill Linke) writes:
> In article <1993Jan7.145511.718@lpi.liant.com>, pkt@lpi.liant.com (Scott Turner) writes:
> > 
> > Identity of objects is more of the essence than storage, so it would be
> > problematic to define the former in terms of the latter.
> 
> Even this is not so clear, is it?  

It may be worth discussing.

> "Identity" means to me that we can
> distinguish between two instances of a class 

Yes.

> using only the attributes of the class itself
> (i.e. without using anything from derived classes which the class
> might happen to be a base class of). This in turn implies that somewhere
> within each instance is some storage which conceptually could hold some
> identifying value.  (Otherwise, there would be no way for two instances to
> have different attributes.)

How could this argument be meaningful?  If I have
       int x=2, y=2;
then in a typical implementation x and y are names of distinct objects,
each of which has storage.  We can conceive of an atypical implementation
which extra allows storage for identifying x and y with distinct keys.  But for
practical purposes all that's necessary is that x and y have different
addresses.  Whether or not the storage can conceptually hold an identifying
value doesn't matter.

If we have objects of a type which requires no state, e.g.
       struct {} a, b;
then in order for them to have distinct identities an implementation
might allocate addresses that don't point to valid memory.  Again, no
storage is required.


When I say that identity of objects is more of the essence than storage,
here's the kind of thing I have in mind:
       int x=2, y=2;
       y = 3;
       // Now the value of x is 2, not 3.  
Why?  Because the declaration defines 2 distinct objects named x and y. 

To explain it in terms of storage is more obscure.  One would
have to say that the storage reserved for the definition of x
is required not to overlap the storage reserved for the definition of y.  
And also mention that the state of the objects x and y resides in the 
storage reserved by their definitions.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com