develooper Front page | perl.perl6.language | Postings from July 2006

Re: Easy Str === Str question: what is a reference type

Thread Previous
David Green
July 12, 2006 14:55
Re: Easy Str === Str question: what is a reference type
Message ID:
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:
>       * $<Object>.id ~~ $<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 

>       * 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 $ return something unique C<but false>?


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About