Larry Wall wrote: > Jonathan Lang wrote: > : 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.
Check, and check. Of course, SUPER:: works well in single inheritence, but runs into problems of "which superclass?" in multi-inheritence; ROLE:: would on the surface appear to have that same problem, except that... > : 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.) (OK.) > : ...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. ...meaning that the question of "which role do you mean?" has already been addressed by the time the ROLE:: "deference" gets used. Although I'm not following what you're saying here in terms of the third means of disambiguation. Could someone provide an example, please? > : 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. Well, the question is: the trait is providing a method with the same name as a method provided by the class, and type information is insufficient to distinguish between them; which one do I use? In the absence of additional conflict resolution code, the possible options as I see them would be: 1) the class supercedes the trait 2) the trait supercedes the class 3) an ambiguity exception gets thrown 4) the trait's method can't be called without explicitly naming the trait Which of these three ought to hold true? Second, where does the additional conflict resolution code go? In the trait, in the class, or somewhere else? > : 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. OK. My concern is that things like properties add new factors to the ambiguity issue that you can't expect the class to know about, because they're being introduced after the class was written. The fact that a role supercedes inheritence makes sense to me (more precisely, it isn't counterintuitive); that a class supercedes a role also makes sense to me, as long as the role was there when the class was defined. But when you add a role to the class after the fact, as in the case of properties, I don't see how you can expect the class to be able to resolve the conflict. What happens when the sticky note that you put on a microwave oven covers up the display panel? It's not so much run-time vs. compile-time as it is "while the class is being written" and "after the class has been written", and the principle that he who knows the most about what's going on should make the decisions. Perhaps this could be handled by requiring "sticky-note" roles (of which properties are a subset) to be explicitly named when their methods are called? That is, "after the fact" roles don't get flattened into the class the way that normal roles do. That way, you're not requiring either the class _or_ the role to resolve the conflict. This would be similar to the relationship between positional parameters and named parameters, in that the latter is there to let you add capabilities to an existing function without disrupting the way that the function normally operates. (OTOH, that's just about _all_ that it has in common.) > : 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.) My apologies; I'm apparently a bit weak on my object-oriented terminology. I'm not quite sure what's being meant here by "metaclass", other than a vague concept that it's somehow similar to the relationship between logic and metalogic. Also, I was under the impression that the writers of the "tTraits" paper that you referred us to disliked "mixins" largely because they _did_ use an order-of-precedence conflict resolution scheme; surely their concerns would apply equally well to what we're calling traits? > 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. As I don't know what AOP is, this is largely lost on me. But I'm all for keeping various aspects of perl orthogonal to each other if it's reasonable to do so. Likewise, my main concern isn't so much "how to supercede a class" as it is "how to keep a class from superceding a role that it doesn't know about". > I'm probably spouting nonsense. I just hope it's good-sounding > nonsense... More importantly, it seems to be _useful_ nonsense. I just hope that _my_ nonsense is more useful than it is annoying. :) ===== Jonathan "Dataweaver" Lang __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
