Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday November 21, 2005
01:17 AM

Applying traits at runtime

[ #27673 ]

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 Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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 whic

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