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;
class methods supercede role methods;
trait methods supercede class methods;
conflicting methods from multiple roles get discarded...
...but the class may alias or exclude any of the conflicting methods to
explicitly resolve the dispute.
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"...
So how do you resolve conflicts between things that supercede the class?
First come first serve (as per slatherons)?
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
