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

      • The Perl6::Roles module supports runtime role composition:

              Name::Of::Role->apply( $some_object_of_unknown_class );

        Can (does/will) Class::Traits support that?
        • It's possible that it will. For the time being, I'm doing some deep internals work with it to make sure that I have everything nailed down. After I feel truly comfortable with its current state I'll start expanding it.

          • I need runtime role composition for DBI v2 prototyping which will be layered over my JDBC module. JDBC can return handles to funky internal Java classes that vary with the driver being used.
            • Currently there is a workaround:

              use Class::Trait;
              Class::Trait->import('TTrait1', 'TTrait2');

              That will properly use those traits, report conflicts, etc. However, it only works once. If both of those traits have identically named methods, the initialize() will fail. The following will not work:

              use Class::Trait 'TTrait1';

              This is because by the time the second trait is used, the meta information for the firs

              • While that would be runtime it's not 'dynamic' (for want of a better word). I looks like I'd have to do something like this:

                        eval sprintf "package %s; Class::Trait->apply(%s);",
                                ref $some_object_of_unknown_class, $trait_class;

                whereas I'd like to be able to do:

                            $trait_class->apply( $some_object_of_unknown_class );

                (which would rebless $some_object_of_unknown_class into a new clas
                • D'oh! Even better:

                  | Mammal |
                  |  Dog   |
                  |  Anon  | (Roles:  Sentry, Tricks, TailChasing, Scratch)

                  With that, a class with a runtime trait applied will have subsequent runtime traits overriding methods in the same anonymous class. The heirarchy is flatter, we use a LIFO strategy for trait method flattening, performance is better and (I think) behavior is the

                  • This is where I'm not sure I'm following you. It sounds like what you want is prototyped OO whereby one can add new methods to an instance and not just to the class itself, is that correct?

                    Yes. Or more specifically, I want to get as close to S12 as possible. I'm hoping you can follow the Perl6 approach to roles ( []) as closely as practical.

                    S12 says compile-time composition merges into one class and detects collisions (as Class::Trait does now), but run-time composition layers on extra anon classes. Very few people will want runtime composition (just me so far!) and I'd guess that most of those who do would be keen to have Perl6 semantics. (The performance difference wouldn't be significant as method lookups are cached.)

                    Also, I'd hope that given

                        $fido = new Dog;

                        $biffo = new Dog;
                    then $biffo could reuse part of the class tree created for $fido. But I guess that's just an optimization.
                    • I don't see $biffo reusing part of the class tree for a few reasons. First, I am hoping to not layer on more than on anonymous class, though I might. Instead, I was hoping to add one anonymous class layer and flatten new traits in that class. That makes things really, really simple. However, there's a catch. If I can apply a trait, I should be able to remove it, too. That means that having a chain of anonymous classes may be the way to go (as removing a trait would effectively be like removing an item

                    • I've no need to remove traits and, as far as I recall, it's not mentioned in S12. Seems like it would greatly complicate the implementation for little gain.

                      S12 does say You can also mixin a precomposed set of roles:

                              $fido does Sentry | Tricks | TailChasing | Scratch;

                      This will level the playing field for collisions among the new set of roles, and guarantees the creation of no more than one more anonymous class.

                      That sounds like it matches what you're proposing (a single anon class