Roles, submethods, constructors, destructors. #103
Comments
|
I'd like to propose a set of rules on treating roles and their composition in to classes. A submethod belongs to where it is defined.Contrary to methods, submethods from roles must not be copied over to the consuming class. The following: must be a Calling a submethod results in a single call.In rakudo/rakudo#2677 it is proposed by @jnthn and backed by @TimToady that if a submethod is declared on both class and and role then calling it on a class instance would result in both submethods being called: My point of view is that there is no reason to break the existing semantics of one call - one (sub)method. For cases where one needs a batch-call there're already Another point is what implicit batch-call must return? How would it handle flattening returns? Also, what would be the way for a user to call submethods individually when it is necessary? Wouldn't implicit batch-call over-complicate this rather simple task? Batch-call of submethods must be possible in reverse MRO.This is quite natural semantics for submethods following how constructors/destructors are being used. But it shouldn't be the only possible way as implicit batch-calling implies. My point of view is that in addition to the mention above Unfortunately, I cannot find appropriate analog for reverse version of Attribute flatteningConsider the example: This code currently results in Attribute '$!a' conflicts in role composition error. This happens because What must happen is |
MRO and
|
|
This is a draft I propose for consideration. It may also be extended to cover rakudo/rakudo#2663. |
Will be useful for submethod traversing when Raku/problem-solving#103 is implemented. Roles are included into `mro` and `mro_unhidden` output when called with `:roles` named parameter. Because roles are integral part of their consuming classes, they always follow their class in MRO list no matter what was the order of declaration. I.e.: ``` class C1 does R1 is C1 does R2 { }; say C1.^mro(:roles).map: *.^name; # (C1 R2 R1 C2 Any Mu) ``` `mro_unhidden` won't include roles of a hidden class into the list.
More on batch-call operatorsIt was proposed more as a joke but suddenly it might make sense to introduce
The above set is sufficient. Questions arise though:
|
Will be useful for submethod traversing when Raku/problem-solving#103 is implemented. Roles are included into `mro` and `mro_unhidden` output when called with `:roles` named parameter. Because roles are integral part of their consuming classes, they always follow their class in MRO list no matter what was the order of declaration. I.e.: ``` class C1 does R1 is C1 does R2 { }; say C1.^mro(:roles).map: *.^name; # (C1 R2 R1 C2 Any Mu) ``` `mro_unhidden` won't include roles of a hidden class into the list.
Will be useful for submethod traversing when Raku/problem-solving#103 is implemented. Roles are included into `mro` and `mro_unhidden` output when called with `:roles` named parameter. Because roles are integral part of their consuming classes, they always follow their class in MRO list no matter what was the order of declaration. I.e.: ``` class C1 does R1 is C1 does R2 { }; say C1.^mro(:roles).map: *.^name; # (C1 R2 R1 C2 Any Mu) ``` `mro_unhidden` won't include roles of a hidden class into the list.
Will be useful for submethod traversing when Raku/problem-solving#103 is implemented. Roles are included into `mro` and `mro_unhidden` output when called with `:roles` named parameter. Because roles are integral part of their consuming classes, they always follow their class in MRO list no matter what was the order of declaration. I.e.: ``` class C1 does R1 is C1 does R2 { }; say C1.^mro(:roles).map: *.^name; # (C1 R2 R1 C2 Any Mu) ``` `mro_unhidden` won't include roles of a hidden class into the list.
|
Closing with merge of rakudo/rakudo#3199 and Raku/roast#581 |
Will be useful for submethod traversing when Raku/problem-solving#103 is implemented. Roles are included into `mro` and `mro_unhidden` output when called with `:roles` named parameter. Because roles are integral part of their consuming classes, they always follow their class in MRO list no matter what was the order of declaration. I.e.: ``` class C1 does R1 is C1 does R2 { }; say C1.^mro(:roles).map: *.^name; # (C1 R2 R1 C2 Any Mu) ``` `mro_unhidden` won't include roles of a hidden class into the list.
Will be useful for submethod traversing when Raku/problem-solving#103 is implemented. Roles are included into `mro` and `mro_unhidden` output when called with `:roles` named parameter. Because roles are integral part of their consuming classes, they always follow their class in MRO list no matter what was the order of declaration. I.e.: ``` class C1 does R1 is C1 does R2 { }; say C1.^mro(:roles).map: *.^name; # (C1 R2 R1 C2 Any Mu) ``` `mro_unhidden` won't include roles of a hidden class into the list.
In this ticket I'd like to gather scattered pieces of one big problem on role composition and submethod handling related to this. Related topics are rakudo/rakudo#2241, rakudo/rakudo#2250, rakudo/rakudo#2677, rakudo/rakudo#2678.
In general, the problem is about:
submethods in roles are composed into the consuming classes and if they should be composed at all?submethods.The text was updated successfully, but these errors were encountered: