Front page | perl.perl6.language |
Postings from July 2006
Re: Easy Str === Str question: what is a reference type
Thread Previous
From:
David Green
Date:
July 12, 2006 14:55
Subject:
Re: Easy Str === Str question: what is a reference type
Message ID:
a06230900c0dae94e7f3f@[172.27.1.7]
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>?
-David
Thread Previous