Smalltalk › Squeak › Squeak - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Casey Ransberger

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

When I (for example,) in a workspace, Command-P the text 'morph3874 color: Color red' and see 'aMorph(2413)', what does the number mean? I'm guessing it's some kind of object pointer. An OOP perhaps, I've heard people speak of those? This has been bugging me for a year, and I can't seem to construct a Google string that finds me an answer to the question. Can I use that number to find the object in the object memory?

Why I ask:

I'm presently trying to understand...

http://bugs.squeak.org/bug_view_page.php?bug_id=456

- Ron the newbie

Michael van der Gulik-2

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

On Wed, Aug 19, 2009 at 4:19 PM, Ronald Spengler <[hidden email]> wrote:

When I (for example,) in a workspace, Command-P the text 'morph3874 color: Color red' and see 'aMorph(2413)', what does the number mean? I'm guessing it's some kind of object pointer. An OOP perhaps, I've heard people speak of those? This has been bugging me for a year, and I can't seem to construct a Google string that finds me an answer to the question. Can I use that number to find the object in the object memory?

Why I ask:

I'm presently trying to understand...

http://bugs.squeak.org/bug_view_page.php?bug_id=456

Look at the code in Morph>>printOn:

Morph>>printOn: aStream
    | aName |
    super printOn: aStream.
    (aName := self knownName) notNil
        ifTrue: [aStream nextPutAll: '<' , aName , '>'].
    aStream nextPutAll: '('.
    aStream
        print: self identityHash;
        nextPutAll: ')'

This gets called when you do alt-p on a morph in a workspace. The second-to-last line is of interest; this is the number that you're seeing. It's an "identityHash". I'm not going to explain hashing here; Wikipedia can teach you more if you're curious.

If you look at the implementation of ProtoObject>>identityHash, it is primitive 75. If you look at the implementation of Object>>asOop, it is also primitive 75. So, coincidentally, yes, it is an OOP (object pointer).

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging. In my own images, I often modify printOn: methods to print out hashes or oops for the same reason.

I'm not sure how you'd convert an oop to an object. I guess you could search through all objects in the image looking for the right one.

Gulik.

--
http://gulik.pbwiki.com/

Casey Ransberger

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

Familiar with hashes. Grok it; I can use it to see if two objects are the same object or not, and looking for a particular object by it's hash is probably expensive.

Thank you:)

On Tue, Aug 18, 2009 at 9:38 PM, Michael van der Gulik <[hidden email]> wrote:

On Wed, Aug 19, 2009 at 4:19 PM, Ronald Spengler <[hidden email]> wrote:

When I (for example,) in a workspace, Command-P the text 'morph3874 color: Color red' and see 'aMorph(2413)', what does the number mean? I'm guessing it's some kind of object pointer. An OOP perhaps, I've heard people speak of those? This has been bugging me for a year, and I can't seem to construct a Google string that finds me an answer to the question. Can I use that number to find the object in the object memory?

Why I ask:

I'm presently trying to understand...

http://bugs.squeak.org/bug_view_page.php?bug_id=456

Look at the code in Morph>>printOn:

Morph>>printOn: aStream
    | aName |
    super printOn: aStream.
    (aName := self knownName) notNil
        ifTrue: [aStream nextPutAll: '<' , aName , '>'].
    aStream nextPutAll: '('.
    aStream
        print: self identityHash;
        nextPutAll: ')'

This gets called when you do alt-p on a morph in a workspace. The second-to-last line is of interest; this is the number that you're seeing. It's an "identityHash". I'm not going to explain hashing here; Wikipedia can teach you more if you're curious.

If you look at the implementation of ProtoObject>>identityHash, it is primitive 75. If you look at the implementation of Object>>asOop, it is also primitive 75. So, coincidentally, yes, it is an OOP (object pointer).

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging. In my own images, I often modify printOn: methods to print out hashes or oops for the same reason.

I'm not sure how you'd convert an oop to an object. I guess you could search through all objects in the image looking for the right one.

Gulik.

--
http://gulik.pbwiki.com/

Casey Ransberger

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

On second thought, that seems weird. Maybe this is just a C background talking, but why call a thing 'pointer' without being able to dereference it?

- Silly Ron, the Newbie

On Tue, Aug 18, 2009 at 9:41 PM, Ronald Spengler <[hidden email]> wrote:

Familiar with hashes. Grok it; I can use it to see if two objects are the same object or not, and looking for a particular object by it's hash is probably expensive.

Thank you:)

On Tue, Aug 18, 2009 at 9:38 PM, Michael van der Gulik <[hidden email]> wrote:

On Wed, Aug 19, 2009 at 4:19 PM, Ronald Spengler <[hidden email]> wrote:

When I (for example,) in a workspace, Command-P the text 'morph3874 color: Color red' and see 'aMorph(2413)', what does the number mean? I'm guessing it's some kind of object pointer. An OOP perhaps, I've heard people speak of those? This has been bugging me for a year, and I can't seem to construct a Google string that finds me an answer to the question. Can I use that number to find the object in the object memory?

Why I ask:

I'm presently trying to understand...

http://bugs.squeak.org/bug_view_page.php?bug_id=456

Look at the code in Morph>>printOn:

Morph>>printOn: aStream
    | aName |
    super printOn: aStream.
    (aName := self knownName) notNil
        ifTrue: [aStream nextPutAll: '<' , aName , '>'].
    aStream nextPutAll: '('.
    aStream
        print: self identityHash;
        nextPutAll: ')'

This gets called when you do alt-p on a morph in a workspace. The second-to-last line is of interest; this is the number that you're seeing. It's an "identityHash". I'm not going to explain hashing here; Wikipedia can teach you more if you're curious.

If you look at the implementation of ProtoObject>>identityHash, it is primitive 75. If you look at the implementation of Object>>asOop, it is also primitive 75. So, coincidentally, yes, it is an OOP (object pointer).

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging. In my own images, I often modify printOn: methods to print out hashes or oops for the same reason.

I'm not sure how you'd convert an oop to an object. I guess you could search through all objects in the image looking for the right one.

Gulik.

--
http://gulik.pbwiki.com/

Michael van der Gulik-2

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

You can change the method name if you don't like it. Generally, you'll never need to learn about >>asOop unless you work on the VM.

Gulik.

On Wed, Aug 19, 2009 at 4:47 PM, Ronald Spengler <[hidden email]> wrote:

On second thought, that seems weird. Maybe this is just a C background talking, but why call a thing 'pointer' without being able to dereference it?

- Silly Ron, the Newbie

On Tue, Aug 18, 2009 at 9:41 PM, Ronald Spengler <[hidden email]> wrote:
Familiar with hashes. Grok it; I can use it to see if two objects are the same object or not, and looking for a particular object by it's hash is probably expensive.

Thank you:)

On Tue, Aug 18, 2009 at 9:38 PM, Michael van der Gulik <[hidden email]> wrote:

On Wed, Aug 19, 2009 at 4:19 PM, Ronald Spengler <[hidden email]> wrote:

When I (for example,) in a workspace, Command-P the text 'morph3874 color: Color red' and see 'aMorph(2413)', what does the number mean? I'm guessing it's some kind of object pointer. An OOP perhaps, I've heard people speak of those? This has been bugging me for a year, and I can't seem to construct a Google string that finds me an answer to the question. Can I use that number to find the object in the object memory?

Why I ask:

I'm presently trying to understand...

http://bugs.squeak.org/bug_view_page.php?bug_id=456

Look at the code in Morph>>printOn:

Morph>>printOn: aStream
    | aName |
    super printOn: aStream.
    (aName := self knownName) notNil
        ifTrue: [aStream nextPutAll: '<' , aName , '>'].
    aStream nextPutAll: '('.
    aStream
        print: self identityHash;
        nextPutAll: ')'

This gets called when you do alt-p on a morph in a workspace. The second-to-last line is of interest; this is the number that you're seeing. It's an "identityHash". I'm not going to explain hashing here; Wikipedia can teach you more if you're curious.

If you look at the implementation of ProtoObject>>identityHash, it is primitive 75. If you look at the implementation of Object>>asOop, it is also primitive 75. So, coincidentally, yes, it is an OOP (object pointer).

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging. In my own images, I often modify printOn: methods to print out hashes or oops for the same reason.

I'm not sure how you'd convert an oop to an object. I guess you could search through all objects in the image looking for the right one.

Gulik.

--
http://gulik.pbwiki.com/

--
http://gulik.pbwiki.com/

ccrraaiigg

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

In reply to this post by Casey Ransberger

Hi Ron--

> ...why call a thing 'pointer' without being able to dereference it?

OOP manipulation happens in the virtual machine; or rather, at the
level where there is no garbage collector beneath you, swizzling them. :)

-C

--
Craig Latta
www.netjam.org

Casey Ransberger

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

Ah, so the GC in the VM swizzles the pointers out from under you.

http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-June/006170.html

Is the above a good summary?

- Ron

On Tue, Aug 18, 2009 at 10:20 PM, Craig Latta <[hidden email]> wrote:

Hi Ron--

> ...why call a thing 'pointer' without being able to dereference it?

OOP manipulation happens in the virtual machine; or rather, at the
level where there is no garbage collector beneath you, swizzling them. :)

-C

--
Craig Latta
www.netjam.org

Bert Freudenberg

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

In reply to this post by Michael van der Gulik-2

On 19.08.2009, at 06:38, Michael van der Gulik wrote:

If you look at the implementation of ProtoObject>>identityHash, it is primitive 75. If you look at the implementation of Object>>asOop, it is also primitive 75. So, coincidentally, yes, it is an OOP (object pointer).

Wrong. You can neither access nor "dereference" OOPs from inside the image.

The comment in Object>>asOop does not reflect reality anymore.

The original (Blue Book) Smalltalk-80 VM used an object table. OOPs were indices into the object table. They were even, because each object table entry stored a 16 bit pointer to the actual object. Odd OOPs represented SmallIntegers in theri upper 15 bits. So the lowest bit indicated whether an OOP was an object table index or an "immediate" integer value. OOPs never changed over the lifetime of an object, garbage collection (which moves objects around in memory) only had to change the object table entry.

In the Squeak VM, there is no object table. It uses a "direct pointer" model. Each OOP is 32 bits (*). Odd OOPs still represent SmallIntegers in their upper 31 bits, but even OOPs are a direct pointer to an object. This means that when garbage is collected and an object moves, its OOP changes. This is not observable from the image.

Now, in Smalltalk-80, #identityHash was calculated as the OOP divided by 2 (they where even, remember? SmallIntegers are their own identityHash), because the OOP was constant for each object, so a good base for knowing identity. In Squeak, an equivalent was needed. There are 12 bits in the Squeak object header that get assigned when the object is created, and are moved around with the object when compacting memory. Primitive 75 returns these hash bits now, despite its name:

primitiveAsOop

| thisReceiver |

thisReceiver := self stackTop.

self success: (self isIntegerObject: thisReceiver) not.

successFlag

ifTrue: [self pop:1 thenPushInteger: (self hashBitsOf: thisReceiver)]

hashBitsOf: oop

^ ((self baseHeader: oop) >> 17) bitAnd: 16rFFF

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging.

Indeed. IMHO, all uses of #asOOP should be replaced by #identityHash (outside of the VMMaker package anyway), and the comment in asOOP updated (or remove it altogether).

- Bert -

(*) Even in a VM compiled on a 64 bit host OOPs are 32 bits. Only in "64 bit images" OOPs are extended to 64 bits, but they are not in use yet. And we might rather like to re-introduce an object table anyway, which even with 32 bit OOPs would give us 2 billion objects ;)

Michael van der Gulik-2

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

On Wed, Aug 19, 2009 at 11:51 PM, Bert Freudenberg <[hidden email]> wrote:

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging.

Indeed. IMHO, all uses of #asOOP should be replaced by #identityHash (outside of the VMMaker package anyway), and the comment in asOOP updated (or remove it altogether).

/me thinks...

I knew that >>identityHash returned bits from the object header, and I knew that Squeak uses direct pointers, but I never put the two together.

I shall remove references to >>asOop in all of my code.

(*) Even in a VM compiled on a 64 bit host OOPs are 32 bits. Only in "64 bit images" OOPs are extended to 64 bits, but they are not in use yet. And we might rather like to re-introduce an object table anyway, which even with 32 bit OOPs would give us 2 billion objects ;)

Nah. Make a block-based VM: http://gulik.pbworks.com/Block-based+virtual+machine.

Then you can have terrabyte-sized images which page to/from disk, and have lots of concurrency in the VM :-).

Unfortunately, the idea is great but it's not on my TODO list.

Gulik.

--
http://gulik.pbwiki.com/

Casey Ransberger

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

This may be my best newbie question ever! Thanks everyone, this has been most informative:)

Is replacing #asOOP with #identityHash bugworthy, do you think?

- Ron

On Wed, Aug 19, 2009 at 3:02 PM, Michael van der Gulik <[hidden email]> wrote:

On Wed, Aug 19, 2009 at 11:51 PM, Bert Freudenberg <[hidden email]> wrote:

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging.

Indeed. IMHO, all uses of #asOOP should be replaced by #identityHash (outside of the VMMaker package anyway), and the comment in asOOP updated (or remove it altogether).

/me thinks...

I knew that >>identityHash returned bits from the object header, and I knew that Squeak uses direct pointers, but I never put the two together.

I shall remove references to >>asOop in all of my code.

(*) Even in a VM compiled on a 64 bit host OOPs are 32 bits. Only in "64 bit images" OOPs are extended to 64 bits, but they are not in use yet. And we might rather like to re-introduce an object table anyway, which even with 32 bit OOPs would give us 2 billion objects ;)

Nah. Make a block-based VM: http://gulik.pbworks.com/Block-based+virtual+machine.

Then you can have terrabyte-sized images which page to/from disk, and have lots of concurrency in the VM :-).

Unfortunately, the idea is great but it's not on my TODO list.

Gulik.

--
http://gulik.pbwiki.com/

Eliot Miranda-2

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

On Wed, Aug 19, 2009 at 6:05 PM, Ronald Spengler <[hidden email]> wrote:

This may be my best newbie question ever! Thanks everyone, this has been most informative:)

Is replacing #asOOP with #identityHash bugworthy, do you think?

Potentially, yes. asOOP is one-to-one whereas identityHash is many-to-one, i.e. oops are unique but identityHashes are not.

- Ron

On Wed, Aug 19, 2009 at 3:02 PM, Michael van der Gulik <[hidden email]> wrote:

On Wed, Aug 19, 2009 at 11:51 PM, Bert Freudenberg <[hidden email]> wrote:

The intention however was just to print out a number that is unique for each different instance so that you can see whether two variables are pointing to the same morph. This is useful for debugging.

Indeed. IMHO, all uses of #asOOP should be replaced by #identityHash (outside of the VMMaker package anyway), and the comment in asOOP updated (or remove it altogether).

/me thinks...

I knew that >>identityHash returned bits from the object header, and I knew that Squeak uses direct pointers, but I never put the two together.

I shall remove references to >>asOop in all of my code.

(*) Even in a VM compiled on a 64 bit host OOPs are 32 bits. Only in "64 bit images" OOPs are extended to 64 bits, but they are not in use yet. And we might rather like to re-introduce an object table anyway, which even with 32 bit OOPs would give us 2 billion objects ;)

Nah. Make a block-based VM: http://gulik.pbworks.com/Block-based+virtual+machine.

Then you can have terrabyte-sized images which page to/from disk, and have lots of concurrency in the VM :-).

Unfortunately, the idea is great but it's not on my TODO list.

Gulik.

--
http://gulik.pbwiki.com/

K. K. Subramaniam

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

In reply to this post by Casey Ransberger

On Wednesday 19 Aug 2009 11:07:29 am Ronald Spengler wrote:
> Ah, so the GC in the VM swizzles the pointers out from under you.
> http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-June/006170.htm
>l
>
This is the classic dilemma between name as an identifier and name as a
locator. The word "pointer" connotes the latter but gets used widely in the
former sense in Smalltalk code. Object Identifier (oid) is unambiguous but
doesn't sound half as cool as oop ;-).

Subbu

Trygve

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

Hi All,
IMO, every object has three essential properties: Identity, State, and Behavior. In Smalltalk, State and Behavior are defined by the object's flattened class hierarchy. The Object ID is not explicitly available. I have am using 'asOop', hoping I get a unique value. But I realize that I am skating on thin ice because its comment confuses me with implementation details. It doesn't say what it means by 'pointer', so there is still hope:

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.

In short:

Smalltalk claims to be object oriented and I regard it as a serious flaw that the object ID is not explicitly visible.
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..
I regard it as a bug that Object>>printOn: does not present some kind of object ID.

Cheers
--Trygve

On 2009.08.20 06:37, K. K. Subramaniam wrote:

On Wednesday 19 Aug 2009 11:07:29 am Ronald Spengler wrote:

Ah, so the GC in the VM swizzles the pointers out from under you.
http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-June/006170.htm
l

This is the classic dilemma between name as an identifier and name as a 
locator. The word "pointer" connotes the latter but gets used widely in the 
former sense in Smalltalk code. Object Identifier (oid) is unambiguous but 
doesn't sound half as cool as oop ;-).

Subbu

--
--

Trygve Reenskaug mailto: [hidden email]

Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver

N-0378 Oslo Tel: (+47) 22 49 57 27

Norway

Adrian Lienhard

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

Oh, don't use asOop. It is useless as an OID as it changes as soon as
the GC moves the object in memory... Pointer here really means a C
pointer.

#identityHash has only a size of 12 bits and hence is quite a weak
hash and useless for an OID.

In short, the concept of an object ID does not exist (unless, of
course, you implement it yourself).

Cheers,
Adrian

On Aug 22, 2009, at 12:39 , Trygve Reenskaug wrote:

> Hi All,
> IMO, every object has three essential properties: Identity, State,
> and Behavior. In Smalltalk, State and Behavior are defined by the
> object's flattened class hierarchy. The Object ID is not explicitly
> available. I have am using 'asOop', hoping I get a unique value.
> But I realize that I am skating on thin ice because its comment
> confuses me with implementation details. It doesn't say what it
> means by 'pointer', so there is still hope:
>
> /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.
>
> In short:
>
> * Smalltalk claims to be object oriented and I regard it as a
> serious flaw that the object ID is not explicitly visible.
> * 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..
> * I regard it as a bug that Object>>printOn: does not present some
> kind of object ID.
>
> Cheers
> --Trygve
>
>
> On 2009.08.20 06:37, K. K. Subramaniam wrote:
>> On Wednesday 19 Aug 2009 11:07:29 am Ronald Spengler wrote:
>>
>>> Ah, so the GC in the VM swizzles the pointers out from under you.
>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-June/006170.htm
>>> l
>>>
>>>
>> This is the classic dilemma between name as an identifier and name
>> as a locator. The word "pointer" connotes the latter but gets used
>> widely in the former sense in Smalltalk code. Object Identifier
>> (oid) is unambiguous but doesn't sound half as cool as oop ;-).
>>
>> Subbu
>>
>>
>>
>>
>
> --
>
> Trygve Reenskaug mailto: [hidden email]
>
> Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver
>
> N-0378 Oslo Tel: (+47) 22 49 57 27
>
> Norway
>
>

Alejandro F. Reimondo

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

In reply to this post by Trygve

Hi,

IMO, an object is something that preserves identity under the pov

of an objerver (the self that reflectOn/know/named "the object");

for me, an object can be open in state and behavior (change in

an unpredictable way) and still be "that object".

Returning to your question about identity, imho it is "something" in the

observer, that reflect on a context through time (here the

virtue of the object-subject relation). The object

preserve the identity in the context known to that

observer (under a pov)

The observer name the object (acording to convenience/role in

the "understanding"/control of the context).

Using a number for the name is primitive but can be understood

as a valid name.

In short, the ID is a name that is defined by the observer when

it is detected a presistence in time of something taking a

role (a model of the observer is the place to implement it).

No need to have an unique ID for each object, because the

universal pov it asumes is a gravitator(innocent) and hide

diversity of observers, the same way as an object realty

is hidden if one assumes a system is defined by one source code.

cheers,

Ale.

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Saturday, August 22, 2009 7:39 AM

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

Hi All,
IMO, every object has three essential properties: Identity, State, and Behavior. In Smalltalk, State and Behavior are defined by the object's flattened class hierarchy. The Object ID is not explicitly available. I have am using 'asOop', hoping I get a unique value. But I realize that I am skating on thin ice because its comment confuses me with implementation details. It doesn't say what it means by 'pointer', so there is still hope:

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.

In short:

Smalltalk claims to be object oriented and I regard it as a serious flaw that the object ID is not explicitly visible.
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..
I regard it as a bug that Object>>printOn: does not present some kind of object ID.
Cheers
--Trygve

On 2009.08.20 06:37, K. K. Subramaniam wrote:
On Wednesday 19 Aug 2009 11:07:29 am Ronald Spengler wrote:
  
Ah, so the GC in the VM swizzles the pointers out from under you.
http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-June/006170.htm
l

    
This is the classic dilemma between name as an identifier and name as a 
locator. The word "pointer" connotes the latter but gets used widely in the 
former sense in Smalltalk code. Object Identifier (oid) is unambiguous but 
doesn't sound half as cool as oop ;-).

Subbu



  
--

Trygve Reenskaug       mailto: [hidden email]

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

Bert Freudenberg

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

In reply to this post by Adrian Lienhard

On 22.08.2009, at 13:15, Adrian Lienhard wrote:

> Oh, don't use asOop. It is useless as an OID as it changes as soon
> as the GC moves the object in memory... Pointer here really means a
> C pointer.

Err, did you not read my explanation further up in this thread? This
is not the case. In Squeak, #asOop is identical to #identityHash. The
comment is wrong.

> #identityHash has only a size of 12 bits and hence is quite a weak
> hash and useless for an OID.
>
> In short, the concept of an object ID does not exist (unless, of
> course, you implement it yourself).

Indeed. I'd also say it's rarely needed, so no big issue.

- Bert -

Adrian Lienhard

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

On Aug 22, 2009, at 17:06 , Bert Freudenberg wrote:

>
> On 22.08.2009, at 13:15, Adrian Lienhard wrote:
>
>> Oh, don't use asOop. It is useless as an OID as it changes as soon
>> as the GC moves the object in memory... Pointer here really means a
>> C pointer.
>
> Err, did you not read my explanation further up in this thread? This
> is not the case. In Squeak, #asOop is identical to #identityHash.
> The comment is wrong.

ups, sorry, I somehow had missed the whole previous thread... And
thanks for the correction.

[...]

Cheers,
Adrian

Bert Freudenberg

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

In reply to this post by Trygve

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.

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?

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"?

I regard it as a bug that Object>>printOn: does not present some kind of object ID.

Has never bothered me.

- Bert -

Bert Freudenberg

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

In reply to this post by Adrian Lienhard

On 22.08.2009, at 17:23, Adrian Lienhard wrote:

>
> On Aug 22, 2009, at 17:06 , Bert Freudenberg wrote:
>
>>
>> On 22.08.2009, at 13:15, Adrian Lienhard wrote:
>>
>>> Oh, don't use asOop. It is useless as an OID as it changes as soon
>>> as the GC moves the object in memory... Pointer here really means
>>> a C pointer.
>>
>> Err, did you not read my explanation further up in this thread?
>> This is not the case. In Squeak, #asOop is identical to
>> #identityHash. The comment is wrong.
>
> ups, sorry, I somehow had missed the whole previous thread... And
> thanks for the correction.

No problem. I just fixed the comment in trunk.

- Bert -

Stéphane Rollandin

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

In reply to this post by Trygve

> In short:
>
> * Smalltalk claims to be object oriented and I regard it as a
> serious flaw that the object ID is not explicitly visible.

In my view, Smalltalk is object oriented: the object is the object is
the object. If an ID was needed, Smalltalk would be Dictionnary
oriented. Precisely because we don't need an ID, objects are first
class. They stand alone and reference one another, they don't need to be
all uniformly referenced by an uber-object.

my 2 cents,

Stef