On Sun, Dec 14, 2003 at 09:05:37PM -0800, Jonathan Lang wrote: : Larry Wall wrote: : > I think the class is still the final arbiter of what its objects : > are--there is no other entity that holds all the reins. If a class : > chooses to include a role, and that role violates the normal rules of : > roles, the class is still responsible for that (or else you need some : > babysitting code somewhere, hopefully in the metaclass). Maybe that's : > what a trait is--a renegade role. : : Let's see if I've got this straight: : : role methods supercede inherited methods;
But can defer via SUPER:: : class methods supercede role methods; But can defer via ROLE:: or some such. : trait methods supercede class methods; I'm not sure traits work that way. I see them more as changing the metaclass rules. They feel more like macros to me, where anything goes, but you have to be a bit explicit and intentional. : conflicting methods from multiple roles get discarded... They aren't silently discarded--they throw a very public exception. (But methods with differing "multi" signatures are not considered to be conflicting, I hope.) : ...but the class may alias or exclude any of the conflicting methods to : explicitly resolve the dispute. Right. Another possibility is that the class's method could be declared to be the default multi method in case the type information is not sufficient to decide which role's multi method should be called. Maybe if it's declared "multi" it works that way. Otherwise it's just called first automatically. : Am I right so far? Maybe not; I noticed earlier that you've mentioned : that roles can be applied at compile-time using "does" or at run-time : using "but"; might _that_ be the defining feature as to whether the role : supercedes the class or vice versa? "does" supercedes inheritence, "has" : and "method" supercedes "does", "is" and "but" supercedes "has" and : "method"... No, I think I'm rejecting that notion as too complicated to keep track of from moment to moment, and too much like slatherons in policy wishy-washiness. The method precedence won't change from compile time to run time. : So how do you resolve conflicts between things that supercede the class? : First come first serve (as per slatherons)? Well, nothing much really supercedes the class. Even traits have to be requested by the class, and if you have an entirely different metaclass, it's probably declared with a different keyword than C<class>. (But sure, multiple traits will have to applied in order of declaration, and I don't doubt there will be ordering dependencies.) I think the normative way to supercede a class should be to subclass it. That's what OO is supposed to be all about, after all. If we can keep that orthogonal to role composition, we stand a good chance of being able to do a lot of what AOP claims to do without the downsides of AOP's own slatheron approach. Or more precisely, we can resort to AOP-style wrappers where we really need them, and avoid them where we don't. I'm probably spouting nonsense. I just hope it's good-sounding nonsense... Larry
