Re^3: Seeking advice for OO-related strategy

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};
[download]

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.

Comment on Re^3: Seeking advice for OO-related strategy Select or Download Code

Replies are listed 'Best First'.
Re^4: Seeking advice for OO-related strategy by blazar (Canon) on Mar 08, 2005 at 15:12 UTC
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};` [download] 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]
Re^5: Seeking advice for OO-related strategy by Tanktalus (Canon) on Mar 08, 2005 at 16:11 UTC
Well, I think that I just pulled stuff out from a bunch of sources. perlobj talks about the "can" method in UNIVERSAL. I think it also talks about how $self ends up as the first param to the object method. perlref talks about the coderefs. Then, the rest of my post was extrapolation from there, plus a little bit of trial-and-error. Other's code: check out the history of CGI::Application. When I first started using it, it handled the two cases (code ref and function name) separately. It now handles them identically (for a fairly significant improvement in speed... at least for that portion of the code). If you want to limit your users to only using function calls, that's fine. Make it look like a function call. Personally, with this syntax, I see little reason to limit the users like that, especially if you're passing $self in anyway. It allows incredible flexibility (callback or inheritance, or both!) with no cost to the base class. All incredibly different from other OO languages. It allows polymorphic polymorphism - you can change the way that you override something completely dynamically. One of the reasons why perl doesn't have access modifiers such as public, private, and protected, is because it's recognised that they often get in the way of getting the job done: what was envisioned by the original designer has nothing to do with what you want to do with it. In the same way, design for flexibility - although you may not see yourself needing it now, the next person to come along may see it being incredibly handy to solve that new problem, and will bless your genius for developing that flexibility ;-)	[reply]