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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Flattened, composable behavior -- sounds like traits [unibe.ch].

    ;-)

    -- dagolden

    • I've read through that a number of times and I think they're right. There are, however, a couple of key differences. First, they don't have state with their traits (see bottom of page two in Traits: Composable Units of Behaviour [unibe.ch]). I think that's a mistake and so does Perl 6 and Moose. Smalltalk traits only share behavior, not data.

      Second, they're not advocating eliminating inheritance. They're advocating eliminating MI and mixins and using traits for allomorphic properties. I'm thinking that perhaps t

      • I agree the local class overriding role can seem confusing, but over the past few years of using roles pretty heavily I have come to appreciate this feature quite a lot. It actually makes the roles more re-usable since it is very easy to locally override something. Yes it does destroy some of the black-box-ness of Roles, but honestly I have not found roles to be very useful unless you can look inside and see what they provide/do. I have come to kind of see Roles as being more semi-transparent then opaque,

        • But for the few times that a local class needs to override a role, why not just have the class explicitly exclude that method from the role? Same effect, but it's explicit, not hidden. So you avoid mysterious breakage and you get closer to how roles were originally intended to be used (a good thing, in this case).

          I realize you probably can't change the API now, but what about use Moose::Role 'strict' or something like that?