On Thu, Feb 12, 2004 at 09:38:47AM -0800, Larry Wall wrote: > Yes, that's a very good paper, which is why Perl 6 now has something > called Roles, which are intended to degenerate either to Traits or > Interfaces. My take on it is that Roles' most important, er, role > will be to abstract out the decision to compose or delegate. But we'd > like them to function as interfaces when the Role is "abstract", > and we'd like them to function as Traits when you don't happen to > specify any state attributes. But for hiding the delegation decision, > you at least have to allow the amount of state that lets you remember > the object you're delegating to. Of course, the Traits paper didn't > go into traits with state, though it did mention it as a future research > topic. We're just doing that future research for them. :-) > > By the way, we distinguish Traits from traits (which are compile-time > properties applied by "is". To apply a Role we use "does".
In a sense, there is no such thing as state. A read-only attribute is a role constituted of one getter method. A write-only attribute is a role constituted of one setter method. A read-write attribute is a role constituted of two methods, one getter and one setter. A noread-nowrite attribute could as well live in a parallel universe. No attributes. It is turtles all the way down. :) More seriously, the mere user of a class has no way to know if he accesses a real attribute or a synthetic one. A synthetic attribute being one that is calculated from real attributes or whose modification affects other attributes. It may interesting to provide syntax to declare the dependancies between attributes even if there is no way to enforce them. > > Larry
