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

      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

      • So it's indeed also like an Abstract class in Java. The solution for the problem in the Java world is the @Override annotation before the overriding method.

        It overrides silently, but it's clear in your code and your IDE will warn you if you don't add the @Override annotation.

        Something like that would indeed save debugging time.


        • No, it's not like an abstract class. I can compose several roles into my class in Perl, but I can't multiply inherit from several abstract classes in Java. Further, if I have two roles which provide the same method name, this fails at composition time but roles (particularly with Moose) offer you a rich variety of ways of resolving conflicts. You don't get that benefit with abstract classes.

          You also mention the silent overriding and the "clear in your code" and "your IDE will warn you". Two problems with this. First, if you add a method to an abstract class and miss one of the classes using it, it's not "clear in your code" because you never saw it. Plus, what if someone is using a different IDE than you are and the @Override annotation doesn't mean anything? Now you're not just forcing a programming language on me and all the programmers who follow you on the project (which isn't a bad thing), but you're also forcing an IDE on me and all the programmers who follow you on the project (which is a bad thing). Serious issues like this should be resolved in the language itself, not in a third-party tool.

          • I see your point about multiple inheritance.

            However, annotations are a language feature and not something IDE-centric.

            • Ah, my apologies about misunderstanding the annotations. It's been too long since I've programmed Java (er, or something like that :)