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.
  • Yes, it is really important that a programmer can see clearly when a trait method is being overridden - just as it is important that it is clear when an inherited method is being overridden.

    I agree with Dr. Black on this point, but this is just language theory and not implementation details. It can be argued that reading the source provides this feature. Dr. Black goes on to say ...

    Similarly, I agree that if the normal Perl environment does not provide good programming tools, then the implementation

    • It is my opinion is that using the alias/excludes feature is a code smell and that more than 3 roles being composed into a single class is a mild code smell that if not watched careful will turn into a full blown stink.

      We have no aliases in any of our role compositions and excludes are used very rarely. I also agree that they're a code smell. As for more than 3 roles, most of our classes use 4 or fewer roles. And we still do use inheritance. Though I tend to think that inheritance is dangerous, I've not gone so far as to completely excise it (except in a spike which was very successful).

      One might think we're overusing roles, but so far, it's worked out extremely well with very few downsides, though I readily admit tha

      • One might think we're overusing roles, but so far, it's worked out extremely well with very few downsides

        Well this is good to hear, perhaps all your examples of edge cases and oddities have skewed my perception of your code base. Although, your anti-inheritance stance does make me think perhaps you've gotten a little too drunk on the role kool-aid.

        I guess my worry is that your not using all the tools at your disposal and therefore wanting to shape the tools you are using in such ways as to compensate. Inheritance is no more evil then roles when used properly, and delegation is sometimes a far superior solution then either of them. Hell, even multiple inheritance can still come in handy sometimes.

        And while I agree that strictness of composition is useful, there is a tradition in the Perl community of giving you enough rope and Moose tries to strike a balance between enough rope and saving you from yourself. But the fact most of your issues stem from (what I perceive as) more extreme or uncommon usage patterns, it makes me think a MooseX module or optional "strict" setting is more appropriate.

        - Stevan