 |
Newsgroups: perl.perl6.language
From: dataweave...@yahoo.com (Jonathan Lang)
Date: Mon, 15 Dec 2003 19:02:53 -0800 (PST)
Local: Mon, Dec 15 2003 10:02 pm
Subject: Object Order of Precedence (Was: Vocabulary)
Larry Wall wrote: Check, and check. Of course, SUPER:: works well in single inheritence, > 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. 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... (OK.) > They aren't silently discarded--they throw a very public exception. > : ...but the class may alias or exclude any of the conflicting methods ...meaning that the question of "which role do you mean?" has already been > : to explicitly resolve the dispute. > Right. Another possibility is that the class's method could be addressed by the time the ROLE:: "deference" gets used. Although I'm not following what you're saying here in terms of the third > : trait methods supercede class methods; Well, the question is: the trait is providing a method with the same name > I'm not sure traits work that way. I see them more as changing the 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 Which of these three ought to hold true? Second, where does the additional conflict resolution code go? In the > : Am I right so far? Maybe not; I noticed earlier that you've mentioned OK. My concern is that things like properties add new factors to the > : 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 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 Perhaps this could be handled by requiring "sticky-note" roles (of which > : So how do you resolve conflicts between things that supercede the My apologies; I'm apparently a bit weak on my object-oriented terminology. > : class? First come first serve (as per slatherons)? > Well, nothing much really supercedes the class. Even traits have 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 As I don't know what AOP is, this is largely lost on me. But I'm all for > 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. 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 More importantly, it seems to be _useful_ nonsense. I just hope that _my_ > nonsense... nonsense is more useful than it is annoying. :) ===== __________________________________ You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||