Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.WHICH doesn't distinguish between instances of identically-named classes #5570

Open
p6rt opened this issue Aug 15, 2016 · 1 comment
Open
Labels

Comments

@p6rt
Copy link

p6rt commented Aug 15, 2016

Migrated from rt.perl.org#128934 (status was 'new')

Searchable as RT128934$

@p6rt
Copy link
Author

p6rt commented Aug 15, 2016

From zefram@fysh.org

my $n = { my class Num {} }().new; my $m = $n.WHICH.Str.split("|")[1].Num; for $n, $m { say (.WHICH, .^methods.elems) }
(Num|47923715919504 0)
(Num|47923715919504 63)

I have here two distinct objects, of different classes, with the same
.WHICH string. One is an instance of an empty class I've just defined,
and the other is a floating-point value in a built-in class. In the
above you can see that they really are of these two different classes
from the different lengths of their method lists.

This is related to [perl #​128931], about .WHICH not distinguishing
identically-named classes, but there's a bit more to this. .WHICH applied
to the two Num classes in the above duly shows "Num" for both, so fails to
distinguish the class objects. But if given instances of two user-defined
classes, I think the object IDs that go into the default .WHICH would
be unique across all the classes, so the .WHICHes wouldn't clash.
The above clash depends on the non-default .WHICH arrangement for the
built-in Num class. Many other classes could produce similar clashes;
generally, custom .WHICH methods are relying on the class part of a
.WHICH string uniquely identifying the class.

-zefram

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant