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.

Not All Features Are Useful (Moose Roles) 9 Comments More | Login | Reply /

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

  • Not completely into Moose yet, but isn't a role the equivalent of a Java interface?

    In that case, the behaviour you describe has been implemented there as a intended feature: a regular class *implements* the interface.

    Additionally, a role seems to also have the function of an abstract class as well. In Java, overriding concrete methods is, again, a feature you want.

    If you don't want to override a method simply do not include a overloading method in the implementing class.

    It looks like a (sensible) design dec

    • Roles are far more than interfaces. I strongly recommend reading up on them to understand what they do. The protect (usually) against method collision and they provide a default implementation. If you want to use one like an interface, it's simple:

      package MyRole::DoesSomething;

      use Moose::Role;
      requires qw(
          save
          search
      );

      And now your classes (or some other role composed into said classes) must provide save and search methods.

      However, if you have this:

      package MyRole::DoesSomethi

      • And the class using the role also has an 'is_deletable' method, than this potentially very important behavior is silently discarded.

        For a definition of "silently" which means "Code I explicitly wrote in my class itself", perhaps.

        What if you extracted all behavior into roles and composed them into classes? I think that would produce the desired results.

        • Still if you redefine a sub in standard procedural code - just as explicitely - you'll get a warning if you have warnings on.

          • Still if you redefine a sub in standard procedural code - just as [explicitly]...

            If you override a method in OO code (the paradigm under discussion) explicitly, you get no warning or error.

            Changing this default behavior is like resolving method dispatch at compile time. That's fine for certain languages, none of which have "Perl" in their names.

            • Overriding methods in subclasses is a standard technique - there is no warning, because it is needed and there is no other way. In the case of roles there is a different way (as the recently anounced solution shows). So why not have this useful warning?

              • Class-local overriding of composed role methods is a standard technique too. It's been in the Perl 6 role specification for years. I have code which relies on it -- and that code predates Moose.

                I fail to understand the value of adding a default warning for intended, specified, useful behavior -- especially behavior you can't accidentally back into.

                • chromatic,

                  FWIW, I agree with you, however a warning cannot hurt and can possibly make it easier to spot problems during heavy role refactoring. And if we find it is more annoying then expected and/or not as helpful as expected, we can remove it as easily as we put it in. The decision made on #moose was that it was a simple enough change and an innocuous enough thing that it was at least worth giving a try. Roles are still a new "thing" and so I still feel like we are exploring some unknown territory here even after using and exploring them for almost 5+ years now (I released Class::Trait 0.01 in 2004).

                  - Stevan

                  • ... a warning cannot hurt...

                    That's completely untrue. This particular warning may not hurt (I don't believe that, but I acknowledge the possibility), but warnings can hurt. I should write a longer post about this. For now, consider take Vista's UAC for examples of supposedly helpful warnings that do, in fact, hurt.

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