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

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.
  • Hi, could you contrast Class::Trait to Class::Role? Thanx!
    • Note that in the following that I do not use the word "role" even though that's the Perl 6 term. This is deliberate to make it clear I'm only talking about Perl 5 traits. Even when I discuss Class::Role I'll call it a trait. Yes, I know that's awkward :)

      Well, first and foremost, Class::Trait [] is the only Perl module to have a substantially complete implementation of traits as described in the classic "traits paper []" that introduced most programmers to traits.

      As for Class::Role, it appears to have the s

      • We are using Class::Role in a very large production system. There were never any problems in installing it.

        You make some very good points about traits there. I was probably thinking too much in terms of "smart Java interfaces" to see the whole power of traits. The reason we originally chose to use Class::Role was the name. I really like the term role, because it creates nice pictures in my head :).

        Basically the only thing we are using roles for at the moment is to implement methods which are empty in the super class of the class that uses the role while only using methods within the role that are guaranteed to exist in the super class. (Does the sentence make sense?). The entities within our OR-Mapper for example can assume certain roles:

        package Thing;
        use base "Entity";
        use Class::Role "Historian";

        An entity that is also a historian will save all changes made to itself within a special history table.

        Thank you for your answer. We will probably switch to Class::Trait for future projects.

        • Are you saying, in your example above, that "Entity" is effectively a Java interface and "Historian" provides the implementations? If so, that's a very interesting way of going about things. I'll have to think about that.

          • That would indeed be an interesting way to go about it :) However, in that case Entity is an abstract class, that provides for database persistence and data relationship management (or-mapping). The abstract class provides for hooks that are filled in by the role.