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
Range.WHICH fails on many kinds of endpoints #5606
Comments
From zefram@fysh.org
Even where it doesn't produce these warnings and an empty representation -zefram |
From @skidsOn Sat, 20 Aug 2016 10:24:51 -0700, zefram@fysh.org wrote:
Unfortunately using the .WHICHs of the endpoints will not be sufficient. For example "Foo^".."Bar" and "Foo"^.."Bar" would put out the same WHICH. Range|(8)|Str|Foo^..Str|Bar ...we could, however, decide whether or not to do so Same problem with Pair, BTW, which already .WHICHs its members: $ perl6 -e '("Foo|Str|2" => "1").WHICH.say' ...and given the use of WHICH in hashing, this is more consequential |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgBrian S. Julin via RT wrote:
Yes, and that's a bigger problem. In general Rakudo's .WHICH methods
The former would be much nicer to work with. -zefram |
From @skidsOn Wed, 30 Aug 2017 07:03:10 -0700, zefram@fysh.org wrote:
OK, a few things to note going forward: 1) the .Str of a WHICH is not Note Range does _NOT_ do so for eqv but seems to punt to comparing WHICH $ perl6 -e 'say ("200^".."foo") eqv ("200"^.."foo")' Second, the spec only says that mutables must produce an ObjAt (and in fact Third, there is a test or two in the current test suite that test for current Fifth, as an aside for non-value-types, even ignoring NUMA, it is not enough to Finally, the cases where we might not present a WHICH.Str which is guaranteed So, I'd suggest the stringification of a .WHICH be of limited length, give a few Meanwhile, implement value-type .WHICHs as either identity or a mixin, and try like Phew. Maybe this was one of those brain pretzels S)2 warned us about. |
From zefram@fysh.orgBrian S. Julin via RT wrote:
One could make that distinction, but then the .Str of the .WHICH would Consider the Set class, as an example user of .WHICH. It needs something
Key question: what value does a colliding .WHICH.Str add? You seem to Even if there were some demand for yet another stringification method, If you're interested in a human inspecting the .WHICH value itself,
That too would break Set and anything else that needs a way to hash
Sure. eqv/=== should absolutely be implemented in type-specific ways -zefram |
From @skidsOn Wed, 13 Sep 2017 10:29:05 -0700, zefram@fysh.org wrote:
I don't think so... and also in answer to:
For example it provides a way to tell with very high probability It can also, if well constructed, tell you whether an unseeded hash
I think for initial hash generation that pretty much boils down (recursively)
I'd hardly rate "being wrong once in a lifetime" at a "nuisance" level Given that WHICH's implementation is purposefully unspecified so it can be
We agree on WHICH.perl and WHICH.gist, and I'm happy to let others
No not really. It's just that the spec specifies that .WHICH is to
I think it is a double-edged sword; It can be useful but has its perils. ...or your implementation could demand all .WHICH produce an object with a There are various ways to skin that cat and unless someone comes up with a Anyway, I don't want to derail this or your other tickets since the .WHICH |
Migrated from rt.perl.org#129019 (status was 'open')
Searchable as RT129019$
The text was updated successfully, but these errors were encountered: