On 7/12/06, Aaron Sherman wrote:
There's a problem here, from my point of view. I'll take it one
assumption at a time:

      * $whatever.as<Object>.id ~~ $whateverelse.as<Object>.id is true
        if and only if $whatever := $whateverelse at some point in the
        past, either explicitly, or through some sort of folding.
      * Str is a boxed type, and thus is a "reference type"
      * Thus, Str should be compared by .id and not by value, according
        to the above.
So, IMHO, either there's a mistake in S03; Str is a special case WRT
===; or I misunderstand "reference type" (which S03 never defines).

Well, Str is "special" insofar as it surely won't rely on the default .id comparison; as I see it, that's something objects get for free, because it makes sense in a lot of common situations (e.g. a typical Person class would consider each instance to represent a different person).

      * Str might be compared by .id, but .id for Str is based on the
        contents of its underlying storage... this worries me because it
        means that Strs with radically different "meanings" would be ===
        because their encoding is different.

Even though S03 doesn't say so, I'm sure that Str's .id will return some sort of value that includes not only the contents but anything else relevant, like the encoding.

As for array-refs, I don't know why they couldn't (or shouldn't) be === if they contain the same values. That seems the least surprising way to go.

A couple of other questions about S03:
Any reference type may pretend to be a value type by defining a .id method which returns a built-in value, i.e. an immutable object or a native value, as specified in S06.

Why does it have to be a built-in value (other than for performance)? It might be useful to return a "value" of some other type, which would in turn be checked for its .id's. Or does the problem lie in not being able to guarantee that we'd ever actually reach real built-in values?

Because Perl 6 uses a false .id to signify a non-instantiated prototype, all instances should arrange to return a .id that boolifies to true.

Does that mean all non-instances are equivalent? I can see that two non-existent Dog's might be considered the same thing, but not a non-existent Dog and a non-existent Cat.
Or will $uninstantiated.id return something unique C<but false>?


Reply via email to