I've just been rereading the recent discussions, and I noticed something that I missed the first time:
Larry Wall wrote: > Traits are not definitional but rather operationally defined in the > worst way. That's why traits are renegade roles. They don't play by > the rules. In other words, a trait effectively has an "installer" routine which gets run whenever you apply it to a particular object (that is, "is const" calls const::INSTALL or something of the sort). I've been trying to puzzle out what the distinction between roles and traits is so that I can understand why traits need to be handled differently than roles are - in particular, I was thinking in terms of why traits don't fit into the "order of precedence" for method calls (that is, class || role || superclass). If I'm right about the installer, the answer would seem to be that the trait gets to choose (by means of the installer) where it fits into said chain, if at all - it could insert itself into the class's ISA list, tell the class to treat it as a role, or maybe even wrest control from the class, effectively treating the class definition as a role or superclass of its own and then masquerading as the class to outsiders (effectively putting itself ahead of the class in the order of precedence chain). Or it could do none of the above, thus requiring its namespace to be explicitly referenced if you want access to any of its methods or attributes. The point is that - if I'm understanding the current thoughts on the subject - the difference between a trait and a role is that a trait's interaction with a class is programmable. How am I faring? ===== Jonathan "Dataweaver" Lang __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
