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.

Class::Trait 0.10 now on the CPAN 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
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 [cpan.org] is the only Perl module to have a substantially complete implementation of traits as described in the classic "traits paper [unibe.ch]" 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');
              Class::Trait->initialize;

              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';
              Class::Trait->import('TTrait2');
              Class::Trait->initialize;

              This is because by the time the second trait is used, the meta information for the first is not available. Any methods in Trait2 which were already in TTrait1 will be silently ignored. There is, however, a reflection class avaiable. I'll see if I can use that so that eventually you can do this:

              use Class::Trait 'TTrait1';

              # later

              Class::Trait->apply('TTrait2');
              • 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
                • [Darn. I hit submit instead of preview.]

                  I just wanted to add a thank you for working on this.

                • 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 class) Both $trait_class and $some_object_of_unknown_class are unrelated to the current package.

                  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? However, I'm not sure that your syntax is good. How would that chai

                • D'oh! Even better:

                  +--------+
                  | Mammal |
                  +--------+
                      |
                      V
                  +--------+
                  |  Dog   |
                  +--------+
                      |
                      V
                  +--------+
                  |  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 ( http://dev.perl.org/perl6/doc/design/syn/S12.html#roles [perl.org]) as closely as practical.

                    S12 says compile-time composition merges into one class and detects collisions (as Class::Trait does now), but r

                    • 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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.