Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
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)

Friday November 18, 2005
02:59 AM

Class::Trait 0.10 now on the CPAN

[ #27630 ]

Thanks to advice from Joshua ben Jore (diotalevi), I have fixed the last known bug in Class::Trait. It's now on the CPAN and I just know that everyone's going to rush out and grab it because MI and mixins suck, right?

Well, no. Probably not. Even though the problems with multiple inheritance and mixins are well known, no one really seems to care that much. They like poking themselves in the eye with a stick because, hey, they don't poke themselves that often and they are used to how it feels.

The bug, by the way, involved trait methods getting flattened into the primary class even if the trait hadn't defined them. Anything which gets exported into the trait was going into your class and I needed to figure out the best way of knowing which methods the trait was really defining. That's when Joshua showed me the way out.

use B 'svref_2object';

sub _sub_package {
    eval { svref_2object( shift )->STASH->NAME };
}

Pass that puppy a code ref and it will return the package the coderef was initially defined in. The following bit is how I use it:

my %implementation_for;

foreach  ( keys %{"${trait}::"} ) {
    my $method = "${trait}::$_";
    next unless defined &$method;

    # make sure we're not grabbing sub imported into the trait
    next unless _sub_package(\&$method) eq $trait;

    if ( /(DESTROY|AUTOLOAD)/ ) {
        die "traits are not allowed to implement $1\n";
    }
    $implementation_for{$_} = $method;
}
$trait_config->methods = \%implementation_for;


List all Journal entries
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 20 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 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
                • [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

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

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

      • By the way: The same deficiency could be pointed out about the base pragma. If it would call import on the super class, an abstract super class could enforce its child the implement certain methods.

        I don't know if Class::Trait implements this, but it should be possible for a class that uses a trait to declare that it it is also a trait or abstract class that requires certain methods to be implemented by child classes. If both traits require a "name" method to be implemented, that should not be a compile t

        • it should be possible for a class that uses a trait to declare that it it is also a trait or abstract class that requires certain methods to be implemented by child classes.

          If I understood you correctly, it sounds like you're asking for traits to be composed of other traits and for all of those traits to specify required methods even if the composite of all of those traits does not provide them, thus requiring the class using the traits to make them available. If that is what you mean, then yes, Class:

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