It sounds like a good use of Class::Trait to me. Inheriting an empty method is a little silly and checking can() can be homophonically ambiguous.

So you're proposing something like:

$o->some_method if $o->does(  'SomeTrait'  )
[download]

?

Just a quick comment.

While does feels very similar to can in this case, it will future-proof things since does('SomeTrait') can indicate the ability to do many methods, while can('some_method') can only ever indicate one.

-stvn

Exactly.

It's also a nice bit of future-proofing in case Perl ever gets multi-dispatch... and that day may be closer than many people think. (I mean dispatch based on role, not structural type.)

If I have a base class I'd just put a no-op method in there.

Alternatively you can also demand that conforming classes provide the no-op method if they don't need that functionality (and possibly provide an "empty" base class for convenience). That way you don't have to inherit from the base class, you just need to have that method defined. Typing sub noop {} isn't that much work, after all.

For example to avoid unnecessary or invalid processing around the method call:

if ($myobj->can('do_something')) {

    my $input = do_something_before();

    my $result = $myobj->do_something($input);

    do_something_after($result);

}
[download]

Or, put it another way, what would you do to me if I published something to CPAN that required the can() crap?

I want to add an optional method to a set of similar classes.

You could just import the method into the classes that need it.

For example, if you created a module like the following,

use strict;
use warnings;

package SpecialMethod;

BEGIN {
   our @EXPORT = qw( special_method );
   require Exporter;
   *import = \&Exporter::import;
}

use ...
use ...

sub special_method {
   ...
}

1;
[download]

then just say use SpecialMethod; from the various classes into which you want to import the method.

Update: Oh wait. That doesn't address your main question at all. I don't think I can give a good answer without knowing more about what you are trying to accomplish, but it sounds like a perfectly reasonable use of can.

Update: Added missing *import = line.

package Base;
sub new { bless \my($scalar), shift }

package Optional;
use Carp qw(croak);

sub optional_method {
    croak q{You said you would implement optional_method and didn't!};
}

package A;
use base qw(Base); # No optional_method.

package B;
use base qw(Base Optional); # Must implement optional_method.

sub optional_method { 'Woot!' }
[download]

I prefer that my inheritance tree go from the most generic to the most application specific, so inheriting from a class whose method(s) will only be used while the wind is out of the south on leap day if it's Tuesday and the moon is new seems much closer to evil than can().

If you have a set of similar classes wouldn't that imply that they share more methods? Or at least have similar methods, seems to me that similar classes = similar methods = derived from a common class, even if that common class is very thin. It really depends though, if you look down the road and don't see them sharing anything else then inheritance might be over kill, but if there is a chance they will overlap more and more you would definitely want to go with inheritance.

Still leaning toward the first way, but I'm curious which of these sounds better to other OO coders. Does the can() approach sound evil?

Not evil, but I'd still prefer the null method option myself. Removes a conditional (which makes the code simpler in my eyes), and gives an explicit sub in the base module to document.