Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Applying traits at runtime 4 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I understand the selector namespace aspect of traints. However, I'm still confused by the need for interfaces within (nested) traits. Can you elaborate on section 3.4 (from the paper)?

    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?

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

      • Yes. And "unsatisfied method requirements which the class using the composed traits must provide" is what I (well, Java) would call an interface. :)

        • 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.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.