Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

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

8 views
Skip to first unread message

Aaron Sherman

unread,
Jul 12, 2006, 11:40:32 AM7/12/06
to Perl6 Language List
S03 says:

Binary === tests type and value correspondence: for two value
types, tests whether they are the same value (eg. 1 === 1); for
two reference types, checks whether they have the same identity
value. For reference types that do not define an identity, the
reference itself is used (eg. it is not true that [1,2] ===
[1,2], but it is true that @a === @a).

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).

Clarification please?

Two things were mentioned on IRC about this:

* 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.
* A reference type might only mean containers (though S03 seems to
imply that objects are included to me).

Thanks, and sorry for all the lame questions! I'm just trying to make
sure that the docs I write aren't utterly, worthlessly wrong. :-/

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback


David Green

unread,
Jul 12, 2006, 5:56:30 PM7/12/06
to Perl6 Language List
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

0 new messages