The lastest version of Class::Trait on my hard drive has experimental support for adding traits at runtime. However, I won't be uploading it right away. So far it works, but I need many more tests to ensure that everything behaves the way it should. There are odd corner cases that most people will never hit but I still need to make sure they work. I've worked on them for hours today and it's time to stop.
If Stevan hadn't made Class::Trait so feature complete, this would have been much easier, but much less useful, too :)
The example they give is difficult for me to follow. How would this be handled in Class::Trait, and under what circumstances would you need it?
Re:Mixing two concepts
Ovid on 2005-11-23T06:47:10
Which paper are you referring to? Do you mean the Scharli paper "Traits: Composable Units of Behavior"? There's no reference to interfaces there so I'm not sure if this is the paper you mean. As a guess, are you asking why composed traits might have unsatisfied method requirements which the class using the composed traits must provide? I can answer that pretty easily, but don't want to spend a lot of time getting into that if it's the wrong question
:) Re:Mixing two concepts
djberg96 on 2005-11-23T12:33:02
Yes. And "unsatisfied method requirements which the class using the composed traits must provide" is what I (well, Java) would call an interface.:) Re:Mixing two concepts
Ovid on 2005-11-23T17:53:26
OK, that's what I thought you meant, but I wasn't sure.
The reason for this requirement is straightforward. Let's say I create a "TSpouse" trait. That trait might provide companionship() and irritation() but still require love(). My class or some other trait has to supply that method. Having single, standalone traits require methods seems fine. For a real example, in my test code I have "XML" and "HTML" traits which require an "attributes" method. That method is provided by my "Data store" trait which looks at the objects fetched from the data store and says what attributes they publicly provide. Thus, the other traits can now access this data from the code without having to implement it themselves.
Now let's say that I want to break my HTML trait into two traits. One requires data store methods and the other does not. Let's say that the trait requiring the data store uses the trait that does not. From the point of view of the consumer, they're still one trait (because they're composed) and they still require an "attributes" method. Unlike the Java interface, I can have those required methods sitting in another trait and just use that other trait.
Did that make sense? It was pretty clear to me, but I may be too close to the problem.
Re:Mixing two concepts
djberg96 on 2005-11-23T17:46:44
Hm...upon further review (Section 3.5) it looks like the interface aspect is only needed for conflict resolution for a class or composite trait.
I think I get it.:)
