[squeak-dev] Re: Newbie Question (about OOPs, maybe) (sorry)

Bert Freudenberg bert at freudenbergs.de
Sun Aug 23 14:36:24 UTC 2009


On 23.08.2009, at 11:42, Trygve Reenskaug wrote:

> Hi Bert,
> My answers inline below.
>
> On 2009.08.22 17:26, Bert Freudenberg wrote:
>>
>> On 22.08.2009, at 12:39, Trygve Reenskaug wrote:
>>
>>> Object>>asOop
>>>     "Primitive. Answer a SmallInteger whose value is half of the  
>>> receiver's
>>>     object pointer (interpreting object pointers as 16-bit signed  
>>> quantities)..."
>>>
>>> ProtoObject>>identityHash
>>>     "Answer a SmallInteger whose value is related to the  
>>> receiver's identity..."
>>> This is pretty vague, but the term 'Hash' indicates that many  
>>> objects can share the same value. So it is clearly cannot be used  
>>> as the objectID.
>>>
>>> The Morph>>printOn: implementation is less than ideal because it  
>>> should apply to all objects, not only Morphs. Also, it should use  
>>> 'asOop' rather than 'identityHash' to let us hope for uniqueness.
>>
>> You might have overlooked that both these methods are identical.
> I do know it and interpret this to mean that the current Squeak VM  
> happens to have unique hash values. There is no guarantee that  
> another version of the VM will have this invariant.

Hashes are non-unique by definition. Indeed, in the Squeak VM they are  
just 12 bits. In the trunk version, asOop now looks like this:

asOop
	^self identityHash

>>> In short:
>>> 	• Smalltalk claims to be object oriented and I regard it as a  
>>> serious flaw that the object ID is not explicitly visible.
>>
>> What if there simply *is* no object ID?
> In Smalltalk, a value is a pointer to an object. Bluebook p. 564:  
> "Each object is associated with a unique identifier called its  
> object pointer. ..."

... digs out Blue Book ...

Yes. This is the VM implementation chapter. IMHO it does not mean an  
OOP has to be accessible from the image as an integer.

> Smalltalk MUST have such unique identifiers to work. I see this  
> pointer as the object's ID. I have seen from the discussion in this  
> track that the VM can actually change this "unique" pointer.

The VM can do anything as long as you can't tell from the image. And  
you can't. OOPs cannot be accessed directly.

> IMO, a Smalltalk user/programmer should not need to understand the  
> VM. Alan Kay' once said something like "everything in computing is  
> about illusions". One such illusion is that the unique object  
> identifier is immutable. When debugging, I also find it useful that  
> it shall be possible to make it visible, but this is not essential  
> for Smalltalk to work.

Object references are immutable. They just do not have an integer  
representation. "Identifier" comes from "identity", and you can test  
identity using "==". This is fact compares OOPs.

>>> 	• We probably need a 64-bit VM to represent it properly, e.g.,  
>>> using the standardized definition of OID, but a value that is  
>>> guaranteed to be unique within the current set of objects would be  
>>> acceptable..
>>
>> What is the "standardized definition of OID"?
> See the Wikipedia article http://en.wikipedia.org/wiki/Object_identifier

I found this page before actually. Nowhere does it say that we need a  
unique integer for every object in a Smalltalk image. This document  
talks about a "hierarchically-assigned namespace", so I did not think  
it was relevant to this discussion.

>>> 	• I regard it as a bug that Object>>printOn: does not present  
>>> some kind of object ID.
>>
>> Has never bothered me.
> I tend to think and work in terms of objects and object structures.  
> Then I need it.


I do, too. I think in terms of objects and object structures - *not*  
of integers to identify them.

- Bert -




More information about the Squeak-dev mailing list