All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

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:)

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.