in reply to Re: Overloading without infinite descent
in thread Overloading without infinite descent (fixed by time: see Perl 5.10.1)

I agree that, if I'm willing to wrap at construction time, then the problem may be solved exactly as you describe. I was just wondering (specifically for the reason that I've described—and because I'm stubborn and want to do something the first way that occurred to me :-)—but more generally because it seems like an interesting, and possibly useful, thing to do) whether it's possible to get at the ‘true’ behaviour of an object which is subject to overloading.

A use case (which is not my actual situation) might go as follows: Imagine that Perl prototypes don't exist, and we're trying to create them. Then one could imagine wanting to write code like this:

package Prototype; use overload '&{}' => sub { my ( $f ) = @_; return sub { check_arguments(@_); goto &$f; }; }; sub i_know_what_im_doing { my $f = shift; goto &$f; }
so that executing
$f->(@args)
would check the prototype, but executing
$f->i_know_what_im_doing(@args)
wouldn't.

(It's not a very good use case, because we have to store the prototype somewhere, and, if we are good and store it in the object, then it's easy to find a way around the problem. :-) )

Replies are listed 'Best First'.
Re^3: Overloading without infinite descent
by ELISHEVA (Prior) on Aug 03, 2009 at 08:07 UTC

    Your question stands on its own merits, of course, but I'm still puzzled as to why one would want to do it. The syntax you describe above could be accomplished without overloading simply by using the wrapped functions reference address as a key into a hash that stores the original code reference. This would also give you the advantage of making the definition of i_know_what_im_doing class specific. Perhaps you could suggest another use case where overloading really is essential? The modified routine for those interested (I expect the OP could easily write it on his/her own).

    Best, beth

    Update: distinguished my question from OP's and clarified my own question which is still about why