> On Jan 29, 2019, at 1:32 AM, yary <not....@gmail.com> wrote: > > https://github.com/rakudo/rakudo/issues/2657 > <https://github.com/rakudo/rakudo/issues/2657> - looks like an outright bug, > to me. > > I don't know about "the big picture" but you hit a not-explicitly-documented > case. > > Referring to > https://docs.perl6.org/language/objects#index-entry-declarator_role-Roles > <https://docs.perl6.org/language/objects#index-entry-declarator_role-Roles> - > > When a role is applied to a class, the methods of that role are copied into > the class. If multiple roles are applied to the same class, conflicts (e.g. > attributes or non-multi methods of the same name) cause a compile-time error, > which can be solved by providing a method of the same name in the class. >
Actually this is the part which makes me unhappy. Perhaps, my thinking is poisoned with Perl5 approach, but I don't consider copying of methods to be sufficient. Again, I would like to see roles as entities implementing some well defined behavior. Having them as limited as just a collection of methods/attributes doesn't make them capable of such job. This is, perhaps, the only issue of Perl6 which makes me unhappy. > I'd like it if roles disambiguated same-name application just as classes did. > Which means, the role they are applied to must have a role with the same name > explicitly calling the methods it wants- compile time error otherwise. Roles > would never participate in MRO, because their "flatness" part of their > attractiveness - there's no guessing which role is providing a method, any > potential name clash is averted by requiring calling out the role or class > providing the desired semantics. Why is it good for roles but not for classes? Would a particular resolution is ever be needed then class/role-qualified calls are always at our disposal. Yet, with current design a programmer discovers the need for the resolution (when using 3rd-party roles) in a hard way – by learning the error messages unless one could remember all the public methods declared. Ok, let's assume that public methods must be remembered. But private? The resolving rule apply to them too! How do I know how they must be resolved without studying the internals of somebody's code? Which could happen to be quite complicated! Yet, as a developer, I would expect a private method to be my method which I can rely upon; and yet – this is not the case. Unfortunately, I can't instantly recall a couple of other problems I had with roles previously. In one case I eventually ended up converting to an abstract class – i.e. instead of declaring method stubs I had to die inside them. There was simply no other solution which would use role semantics. This is the whole point of my message. The bugs? They'll be fixed eventually. Though for me it would be too late perhaps and my code would use another route to the target. But the fundamental issue will remain: the language has an entity with artificially limited functionality "because it's conceptually right". BTW, I consider this a very Java/Python/Pascal way: constraining for constraining and to dictate the developer the right ways of doing things. > > Through that lens, my thoughts on > https://github.com/rakudo/rakudo/issues/2282 > <https://github.com/rakudo/rakudo/issues/2282> - ought to run without error > https://github.com/rakudo/rakudo/issues/2496 > <https://github.com/rakudo/rakudo/issues/2496> - my edits/comments > role X { method f { say "f" } } > role Y does X { method g { say "g" } } > class C does Y {} > > C.new.Y::g; # works > C.new.Y::f; # works > C.new.X::f; # LTA error. But with roles doing "flat" copying don't have an > expectation that C knows the name "X", > # I only expect that C can call method f which it got from Y, and that did > work. This looks reasonable. I would suggest you commenting on the bug report. It would be useful to both the reporter and a core developer who's gonna consider the report. Best regards, Vadim Belman
