p6rt
commented
9 years ago From @Ovid
The following code prints "Int": multi f(Int $f where * \< 20) {"Int" } multi f(Int $f where * > 0) { "greater" }; say f(3) I'm told that "earlier wins", but sub resolution shouldn't be ambiguous. This is even worse with roles: role R1 { multi method foo(Int $f where * > 0) { say "R1" } } role R2 { multi method foo(Int $f where * \< 10) { say "R2" } }; class C does R1 does R2 {}; C.new.foo(3) # prints R2 Versus (note the role consumption order): role R1 { multi method foo(Int $f where * > 0) { say "R1" } } role R2 { multi method foo(Int $f where * \< 10) { say "R2" } }; class C does R2 does R1 {}; C.new.foo(3) # prints R1 Now the order of role composition is important, but avoiding that is part of the reason roles were invented in the first place (http://scg.unibe.ch/archive/papers/Scha02cTraitsModel.pdf). It's a potential maintenance nightmare. Some developer, trying to make the code more readable, sorts the roles alphabetically and breaks the code via mysterious action at a distance. This is perl6 version 2014.12 built on MoarVM version 2014.12
Best,Ovid-- IT consulting, training, international recruiting http://www.allaroundtheworld.fr/. Buy my book! - http://bit.ly/beginning_perl Live and work overseas - http://www.overseas-exile.com/
Migrated from rt.perl.org#123577 (status was 'new')
Searchable as RT123577$