Abstract Methods in Moose

[crashtest]

Greetings, wise monks!

After about a year's hiatus, I've recently found an excuse to return to Perl, and decided to finally take Moose out for a spin. After years of using AUTOLOAD to generate accessors/mutators, I feel like I've been (poorly) reinventing wheels when better alternatives were right there on CPAN. Well, no matter...

Probably because I've spent too much time programming in Java, I get this urge to declare abstract methods. I realize the benefit isn't there when using Perl as opposed to a statically typed/compiled OO language such as Java, but I like to clearly point out methods I expect subclasses to implement. So right now, I've written something like:

package AbstractWidget;

use Moose;
use Carp;

sub get_widget_type{
    confess(qq["get_widget_type" must be implemented by a subclass!]);
}

Now if I forget to implement get_widget_type in my SnazzyWidget class, I get a helpful error message with a stack trace instead of the rather cryptic and confusing "Can't locate object method "get_widget_type" via package "SnazzyWidget"".

I half expected to find a Moose extension that would allow me to express this more concisely, providing a method like

has_abstract 'get_widget_type'

or

expects 'get_widget_type'

I've done some searching on both PerlMonks and CPAN to no avail. Is my interest in abstract methods misplaced? Or is there some other pattern Moose'ers employ that has a similar effect? Any input you have for me is much appreciated!

I had a suspicion that Moose Roles might lead me to a satisfactory solution, but apparently others have had the same idea... and the manual is quite clear about this:

If you are familiar with the concept of abstract base classes in other languages, you may be tempted to use roles in the same way.

You can define an "interface-only" role, one that contains just a list of required methods.

However, any class which consumes this role must implement all of the required methods, either directly or through inheritance from a parent. You cannot delay the method requirement check so that they can be implemented by future subclasses.

[stvn]

Perhaps MooseX::ABC is what you are looking for?

You should be able to extend your abstract base class with other abstract classes too (like you show in your example in here). You should also note that roles can be composed of other roles, so this will do what your looking for:

package WidgetRole;
use Moose::Role;

requires 'get_widget_type';

package AbstractWidget;
use Moose::Role;

with 'WidgetRole';

package SnazzyWidget;
use Moose;

with 'AbstractWidget';

sub get_widget_type{ "BasicWidget" }

[crashtest]

I hadn't seen MooseX::ABC - apparently its author's intent was the same as mine, but there are some limitations in the implementation.


Read more... (974 Bytes)

OK, but what you say about "specializing" or extending roles was a big eye-opener for me. I was caught thinking in terms of the Java paradigm, thinking of the Moose Role as something to be added into the base class. Instead, what works is when the Role itself acts as the base class, as you illustrated (and Anonymous Monk hinted at). I'm then free to extend/specialize the Role if I want.

The only thing that seems to suffer a little is the terminology - when I say that SnazzyWidget is with 'AbstractWidget', that implies that Snazzy Widget can in fact exist without Abstract Widget if it wanted to, which isn't true. But I think that's a consequence of this base class / concrete class model I have in my head, and my naming of the packages. If I called AbstractWidget something like Typeable instead - the class names would work together better, I think.

Thanks for your input, and also thanks much for your work on Moose. I've barely scratched the surface but I like what I've found so far. I mostly write throw-away Perl scripts for random ad-hoc data processing tasks. I like to model things in terms of OO, but have often shied away from it because of some of the verbosity and opaqueness (my $self = shift;, bless $self, __PACKAGE__, writing accessors etc.) of Perl 5 OO programming. Moose looks to have made it much more natural to work with objects in Perl 5.

[stvn]

It looks like the existence of the method to be implemented is asserted at class definition time, not during instantiation. As a consequence, the program dies unless the abstract method is implemented in the immediate subclass. So once again, it is not possible to "defer" implementation to an arbitrary child class.

Sorry for giving the false info, turns out this is listed as a TODO in the docs, I dove right into the source code to see and misunderstood it. I have notified the author though.

I think roles is a better fit here, you just need to work out the details of naming (which you are already well on your way to doing). I tend to go with two different role naming approaches; Fooable, when providing mostly just behavior, and WithFoo when providing attributes and accompanying methods. Sometimes for more "interface" type roles I will follow something closer to the normal abstract base class naming conventions (see Forest::Tree and Forest::Tree::Reader, Forest::Tree::Writer, Forest::Tree::Loader, etc).

[stvn]

As a consequence, the program dies unless the abstract method is implemented in the immediate subclass.

Take a look at the Changes file for 0.03, it should work now.

[brap]

I could be way off (just trying to learn Moose myself), but are you maybe looking for

requires 'get_widget_type';

in the base class by chance?

[crashtest]

Hm. I believe the requires is provided by Moose::Role, and hence has the limitations outlined in the documentation.

What it comes down is that while I can use a role to require a method definition directly in a class, I can't "defer" the method definition until later in the class hierarchy. That is, the following would work:

package WidgetRole;
use Moose::Role;

requires 'get_widget_type';


package AbstractWidget;
use Moose;

with 'WidgetRole';

sub get_widget_type{ "IAmAbstract" }

but the following (which is what I'd want) wouldn't:

package WidgetRole;
use Moose::Role;

requires 'get_widget_type';


package AbstractWidget;
use Moose;

with 'WidgetRole';


package SnazzyWidget;
use Moose;

extends 'AbstractWidget';

sub get_widget_type{ "BasicWidget" }

# throws error and dies

So I don't think roles/using requires is what I am looking for. But maybe I'm wrong - I have all of five days of experience with Moose!

[ikegami]

Why do you have a role and and a base class? You should use a role instead of a base class. All you need is

package Widget::Role;            # Formerly Widget::Abstract
use Moose::Role;
requires qw( get_widget_type );  # Abstract methods
...                              # Other attributes and methods.
1;

package Widget::Snazzy;
use Moose;
with qw( Widget::Role );
sub get_widget_type { __PACKAGE__ }
...
1;

[Anonymous Monk]

imho roles are theabstract part and the class that consumes is muchh more concrete

[chromatic]

Why is a role without implementations unsatisfactory?

[crashtest]

The issue was with consuming the role and trying to leave the required methods' implementation to a subclass (example)

Using the Moose Role as a sort of base class on its own (possibly adding some concrete common details) allows it to be extended/specialized like I wanted, and is satisfactory. stvn pointed this out.