Am Freitag, den 10.07.2009, 17:06 -0700 schrieb Jon Lang: > How about this: in role composition, "mandate" causes methods to take > precedence over other methods with which they would normally conflict, > and to conflict with methods that would normally take precedence over > them.
I really dislike this because it is contrary to the original idea of the "stateless traits" as defined in the original paper from Nathanael Schärli. The main reason why "traits" have been introduced was to solve the problems inherent to mixins. In mixins the main problem is that the class using the mixin is not able to control the composition (which is simply done sequencially) and that lend to fragile hierarchies. The brilliant idea with "traits" is that it bring back the control to the class consuming the "trait" and conflicts have to be solved explicitly. The traits paper propose 3 different operators to solve such conflicts: overriding, excluding or aliasing. I definitively think that perl 6 roles should also have an excluding operator because I think that *every* composition conflicts arrising should be solvable by the class comsuming the role. What you propose here is a step behind: you reintroduce the problem existing with mixins by bringing back precedence rules in the way composition is made. So far, I have only seen reference to the original paper decribing the "stateless traits". As roles are an implementation of "stateful traits", maybe we should start to point to the paper formalising it: http://scg.unibe.ch/archive/papers/Berg07eStatefulTraits.pdf > So: > > role R1 { mandate method foo { ... } } > role R2 { method foo { ... } } > class C does R1 does R2 { ... } > > Normally, the compiler would complain of a conflict between R1 and R2; > but because R1::foo is mandated, it wins out. > > role R { mandate method foo { ... } } > class C does R { method foo { ... } } > > Normally, C::foo would take precedence over R::foo; but because R::foo > is mandated, the compiler complains of a conflict between C and R. > > When two methods have the "mandate" keyword, they are compared to each > other as if neither had the keyword. > > role R { mandate method foo { ... } } > class C does R { mandate method foo { ... } } > > Since both R::foo and C::foo are mandated, C::foo supersedes R::foo. > > Applying the "mandate" keyword to a role is shorthand for applying it > to all of its methods. > > mandate role R { > method foo { ... } > method bar { ... } > method baz { ... } > } > > is the same as: > > role R { > mandate method foo { ... } > mandate method bar { ... } > mandate method baz { ... } > } > > This behavior can be overridden by the "suggest" keyword: > > mandate role R { > suggest method foo { ... } > method bar { ... } > method baz { ... } > } > > is the same as: > > role R { > method foo { ... } > mandate method bar { ... } > mandate method baz { ... } > } > > That is, every method is either mandated or suggested, and suggested > by default. Mandating a role changes the default for its methods, or > you could explicitly suggest the role. The latter possibility would > allow for a pragma that changes the role's default importance from > suggested to mandated. > > Ovid's distinction between interface and unit of behavior could be > managed by this distinction: "suggest role R" is primarily intended as > an interface, with behavior being a suggestion only and implicitly > overriden by the class; "mandate role R" is primarily intended as a > unit of behavior, and overriding its behavior requires that you > explicitly supersede it. In Ovid's programs, he might start by saying > "use mandate", so that roles operate as units of behavior by default, > and can be declared as interfaces by saying "suggest role" instead of > "role". Or maybe the pragma declares "interface" as a synonym for > "suggest role". (I'd be more comfortable with this if I could think > of a comparable synonym for "mandate role"; at that point, you could > do away with the pragma - use "role", "suggest role", or "interface" > to mean "interface", and use "mandate role" or ??? to mean "unit of > behavior".) > > At this point, you can strengthen the importance of a method (raising > it from a suggestion to a mandate); but you cannot weaken it. Thus, > interfaces can be composed into units of behavior; but not vice versa: > attempting to do so would result in a unit of behavior. I think that > the converse _should_ be possible; but I'm not quite sure how it might > be done. >
