One of the beauties of the original Traits paper was that its roles had ways of specifying assertions of what criteria must be met by whatever classes they were to be composed into. Meanwhile, it's been mentioned that roles and classes in P6 might look declarative in nature, but they are in fact procedural.
So why not allow a few assertions to be made in roles? These would be assertions which get run by the class when it composes the roles, and returning false would raise an exception to the programmer, quite possibly providing at compile-time some detailed information as to what he left out of the class. So instead of having to hunt through a bunch of code inside a method to find that there's a reference to an attribute $.x, he'd get an error message triggered by an assertion that the class must have an attribute $.x. Or: role A { $::_ can x; # asserts that the class must provide a method called x method y () { # a whole bunch of code # a line that makes reference to $.x # a bunch of additional code } } class Foo { does A; }; This would produce a compile-time error "class Foo can't x as role A requires" instead of a compile-time error "$.x undefined" or somesuch, which is what you'd get without the "can" assertion. The code would work either way; the difference is in how much debugging is needed for a programmer to find and correct his mistake. IMHO, code which serves no other purpose than to produce speedy and intelligent error messages is still quite a valuable thing. ===== Jonathan "Dataweaver" Lang __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash