The only thing I normally do different in cases like this would be the following:
sub parse {
my $self=shift;
my $meth = $self->{_action} || die "Missing action";
Well, of course I actually do validate my input in real code, I only wanted my minimal example to stay really... ehm, minimal!
As a side note I would have done the validation in the constructor (or wherever the subref is actually passed in), and I would have checked that it is a subref.
$self->$meth(@_);
Just woke up in the morning, but... shouldn't that be
$meth->(@_);
instead? | [reply] [d/l] [select] |
This is among some of the coolest aspects of perl, IMO.
Assuming $meth is a coderef, $self->$meth(@_) is exactly the same as $meth->($self, @_). However, if $meth is a string which holds the name of a function, then they aren't the same. The rules get a bit convoluted here:
- $meth->($self, @_) does not work with strictures. Without strictures, it should only look in the current package for a function named as per $meth, and then is the same as $self->__PACKAGE__::$meth(@_) (if that is even legal code).
- $self->$meth(@_) does work with strict. It uses standard inheritance rules to find the function named as per $meth, which means starting with the package named as per "ref $self" and going up the @ISA tree.
This means that your validation should not check merely that the action parmaeter is a coderef, but also that $self can do it:
$self->{_action} = ref $_[0] ? $_[0] : $self->can($_[0]);
die "Invalid action" unless $self->{_action};
If you're passed a coderef, use it. If not, you can convert it into a coderef that has already gone through the @ISA tree to find the right function.
| [reply] [d/l] [select] |
This is among some of the coolest aspects of perl, IMO.
Assuming $meth is a coderef, $self->$meth(@_) is exactly the same as $meth->($self, @_).
Indeed it's cool, if not for anything else for I had never noticed it either in the docs or in others' code!
BTW: do you know where all this is documented? I know I can find it myself, but maybe you can direct me straight to the entry point(s) in the docs...
Said this, however cool this syntax is, I am not sure if I want to adopt it with callbacks. I mean, I'm reasoning in terms of psychological L&F (or UI, if you prefer): if I'm basically doing a function call, and I am sure it will be a (subref dereferencing followed by a) function call, then I want it to look like a plain function call, not like I'm accessing a method. Maybe it's just me anyway...
However, if $meth is a string which holds the name of a function, then they aren't the same. The rules get a bit convoluted here:
All in all it seems to me that it's just another instance of "symrefs vs 'real' refs", or is there anything substantial to it?
This means that your validation should not check merely that the action parmaeter is a coderef, but also that $self can do it:
$self->{_action} = ref $_[0] ? $_[0] : $self->can($_[0]);
die "Invalid action" unless $self->{_action};
If I got it right this will "only" be useful if I want to mix callbacks and (methods) inheritance, which I can see could be an interesting option in some cases, but in this case if I simply want to use the former ones, then I wonder if this is the Right Thing(TM) to do...
| [reply] [d/l] |