Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))

[James Mastros]

On 12/12/2002 5:50 AM, Aaron Crane wrote:

Damian Conway writes:

There's no need for special methods or (gods forbid) more operators.
Just:

    $obj1.id == $obj2.id

That's what the universal C<id> method is *for*.

How universal are universal methods?

That is, can a programmer override .id() in a user-defined class? If so,
simply comparing .id for numeric equality isn't a good enough way of
comparing object identity.

I'd say that you can override .id, but if you do, you deserve what you get. That is to say, if your .id method lies, and somebody tests that two objects are the same with .id, you should be sure that you're prepared to accept all the complications of answering the way you do.

Also, it's likely that .id will be implemented with a single Parrot opcode, so you'll loose a lot of efficency by overriding it.

Another question. Consider the integer 17. There are two plausible
representations for it -- one boxed, and one unboxed. There might also
be several distinct boxed 17s that aren't object-identical. My question
is whether all of those should have the same .id().

Here's my basic defintion of ID: Two things should have the same ID if-and-only-if they will behave exactly the same, now and forevermore.

Thus, there should be one ID for all constants of the same value, which is different from all constants of different value. (This is probably unimplementable if we gaurntee IDs are of some constant length.)

Two objects should only have the same ID if they are aliases of each-other: they always have the same instance values, and the same value (but) properties.

Promotable, but unpromoted, Ints should have different IDs, because they may at some point, have different values.

Any unconsidered cases?

That is, should the
programmer be allowed to determine whether two apparently-identical
numbers have the same representation, or should .id() fudge the issue by
pretending that all representations of a number of a given type are
identical.

Some of both. Not all constants of the same number neccessarly have the same reprensentation in PBC -- to whit, a constant float in different compilation units will get different slots in the constant table, but are really identical. The same is true of constant strings. (Constant integers are inlined, and thus this doesn't apply to them -- they really are identical.)

-=- James Mastros