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

      • It seems to me that it would be useful for Perl(5|6) to make method overriding explicit as Java has done. Similarly, I'd like to see it made explicit when you're overriding a role method with a method defined in a class. As a compile-time error.

        So I think it'd be useful for you, Ovid, to implement a MooseX module that does this a al Stevan's suggestion. Then there'd be a feature that you could point people to using.

        Stevan, FWIW, in Smalltalk the browser isn't just a tool, it's effectively part of the language. And although most Java programmers use tools (Eclipse), the @Override syntax has still been added to the language itself. So when the tools are not part of the language (as Perl::Critic is not required to write Perl and Eclipse is not required to write Java), I think that a feature of the language should be provided for you to be explicit about when you're overriding a method.

        If Ovid can demonstrate this as useful in a MooseX module, so much the better.

        My $0.02.


        • As a compile-time error.

          ... as an optional compile-time error or warning or whatever.

          Warnings and errors are affordances. A default error or warning on this behavior pessimizes legitimate, intended, and explicitly designed uses of the feature.

        • I do have MooseX::Role::Strict [] on the CPAN. It's already uncovered several issues here at work (we had managed to work most of them out the hard way before we switched over to this). Maybe I should add MooseX::Role::Warnings to that distribution?

        • Who's going to start championing the patch to P5P that we need this feature in the Language?

          One of Moose's driving goals (which we do lose site of occasionally) is that it is Perlish. This feature (right or wrong) is not how Perl currently interprets overriding inherited methods. There are several places where Moose tries to be more strict about things than default Perl (strict/warnings enabled by default for example, though 5.11 enables strict as part of "use 5.11") and several places where things that Ste

          • Who's going to start championing the patch to P5P that we need this feature in the Language?

            I'm not sure it's possible with the language as currently implemented, unless for every method dispatch you walk the C3 ordering of ancestors looking for homophonic functions and accept that AUTOLOAD will provide a lot of ambiguity or expect everyone to override UNIVERSAL::can correctly.