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
Sets (and Bags and Mixes) are exposing allomorphs and are generally very type sensitive #5842
Comments
From @dwarringOne example from this stack overflow question: question my $num_set = set( < 1 2 3 4 > ); As noted is the thread it's unexpected and a likely trap that's The current implementation is supposed to make it easy to form sets of my $v = 42; Applying a role to the object has had the side effect. Its no longer I suspect the general idea of using .WHICH as a discriminator between Maybe we should pull this back and use something simpler and more |
From @zoffixznetOn Wed, 30 Nov 2016 10:18:50 -0800, david.warring wrote:
Thanks for taking time writing this up, however, I'm going to reject this ticket. There's little reason to make a major, breaking change to a large feature of the language, making it much less powerful, just because a single beginner used poor documentation and got confused. The author of that SO question created another ticket (RT#130184) and the documentation has since been amended to explain that `< ... >` quoters differ from qw// quoters and that they create allomorphs. Feel free to submit further improvements to either allomorphs or set bag mixes page (https://github.com/perl6/doc/blob/master/doc/Language/setbagmix.pod6 ) I'd even argue the allomorphs alone are the cause of that person's confusion and not setties and baggies using object identity to discern their elements. And aside from edge case where the angle brackets double as numeric literals, they're pretty easy to explain to beginners: for numbers, you get a subclass of Str and a particular Numeric, since the parser doesn't know which one you meant and making them all Str would make the feature less useful. If you meant a specific numeric type, coerce the stuff you get, if you meant always Str, use qw// quoters instead (there's also http://modules.perl6.org/dist/Quantum​::Collapse module). If a set based on .Str is needed, one can use set <1 2 3 4>».Str. The proposal to use .Str instead of object identity would make ['a', 'b', 'c'] be equivalent to element ['a', ['b', ['c']]], or [[['a'], 'b',] 'c'], or string 'a b c', or class Foo { method Str { 'a b c '} }. In fact, it'll also treat all of these as the same object: class { method bar {} }, class {}, class { has $!foo }; class A {}; class B is A {} because all of their .Str is an empty string. This would make the feature rather error prone.
That's because it's a completely different object. Even with the .Str proposal that can be effected, since `"foo"` and `"foo" but "bar"` would not be considered the same items in the set, since their .Str values are different. In summation, I don't think power should be stripped from features for the sole reason of making them more palatable to absolute beginners. Improved documentation is the correct solution. Cheers, |
The RT System itself - Status changed from 'new' to 'open' |
@zoffixznet - Status changed from 'open' to 'rejected' |
From @dwarringNo worries. I wasn't coming from just stripping them out completely (they are a good feature), but just somehow having them disabled by default to reduce the element of surprise. Something like how the Hash family operates. Cheers, On Wed, 30 Nov 2016 11:28:49 -0800, cpan@zoffix.com wrote:
|
Migrated from rt.perl.org#130222 (status was 'rejected')
Searchable as RT130222$
The text was updated successfully, but these errors were encountered: