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.

The Original Trait Researchers on the "Class Wins" Issue 20 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Do you also want using 'sub foo {...}' to override a superclass method to be a compile-time failure or warning?

    If not, why treat it differently than overriding a role method, other than one's comparative level of experience and familiarity with inheritance vs. with roles?

    • Do you also want using 'sub foo {...}' to override a superclass method to be a compile-time failure or warning?

      Many language designers are now realizing that they need to be explicit in their code behavior. For example, here's a Java method which should override a parent class method.

      @Override
      public int someObscureMethod() {
         return 1;
      }

      What if the parent class method takes an argument? You've not overridden the method and you may very well get an extremely hard to debug error. Now you can find out at compile time that this method isn't really overriding anything. Here's the method in C#

      public overr

      • I think hdp was asking an honest, simple question. I think your answer is "yes, subclassed override should also warn if not marked," with added explanation. Is that correct?

        I have no strong feelings either way, although I'd rather all my existing code didn't go crazy with warnings. I just wonder what your opinion is on other forms of method occlusion or augmentation.

        --
        rjbs

        • Yes, that was my intended answer. Many languages are moving to this, though I can see others resisting this idea.

          As for "other forms of method occlusion or augmentation", I expect you're referring to things like the "before", "after", "around", "augment" and "inner" features from Moose. "augment" and "inner" must go hand-in-hand, so that's immediately visible to the programmer no matter which of the augment/inner methods they see.

          The others are silent "action at a distance" but they have the advantage tha

  • Specificaly it's here: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo/Perl-Critic-Dynamic-Moose.g it;a=summary [shadowcat.co.uk]

    I'm not sure why it wasn't released, I know that Sartak was looking for feedback. My guess is that nobody provided the feedback so it didn't get used.

    I find the comments that Smalltalk doesn't have this problem because it has tools, and that you don't use Perl::Critic (a tool) so the solution that a member of the Moose Team has provided is useless, rather insulting to one of my friends a co-de

    • I'm very sorry I gave offense. I didn't mean to, but it's clear I phrased that very badly. I've just not been in the habit of using Perl::Critic. If given tools are ubiquitously adopted (e.g., the Smalltalk browser) or varying tools offer the same basic functionality (various Java IDEs) and are ubiquitously adopted, then tool support for features like might be very reasonable.

      I suspect (though I can't prove) that many Moose developers aren't using Perl::Critic and thus aren't likely to benefit from this,

      • I've just not been in the habit of using Perl::Critic. If given tools are ubiquitously adopted (e.g., the Smalltalk browser) or varying tools offer the same basic functionality (various Java IDEs) and are ubiquitously adopted, then tool support for features like might be very reasonable.

        Perl::Critic is an invaluable help and is well integrated for example in EPIC or Padre (with Padre::Plugin::PerlCritic). If you have pointers on how to do it with Vim or Emacs, I would be happy to ear it :) An other possibility could be to use a precheck hooks in cvs/svn/git/whatever running perlcritic with the according .perlcriticrc (pointers to hook scripts also welcome :) As a senior developer you should definitively use it and more than that you should promote it in your team! One of the job of an s

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

        • 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 [cpan.org] 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.

      • 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

    • Oh, and as for "Here we go again", I'm not asking for or expecting any changes to Moose in this regard. I only raise this issue because there seemed to be some confusion on the part of some (perhaps myself) about why the behavior is the way that it is.

      • Yeah sorry, that was an bad title written off the cuff and then not really considered, I didn't mean it as snarky as it sounds :)
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.