http://qs321.pair.com?node_id=228440


in reply to Why isn't ->can() curried?

When I have wanted to use can for anything other than the truth value I have generally wanted to either verify which function implements it (which your suggestion breaks) or else I have wanted to wrap the existing implementation with another and it is not certain that I want to necessarily use the same object. Indeed I might locate can with the class and then feed it real objects later.

I don't want to do either often, but on the rare occasions when I do, your suggestion is less convenient than the current behaviour.

But more than that, the vast majority of the time when people want to check can they just want to check truth. Why create a closure just to see it get thrown away?

But if you really want it, just create another method to do what you want:

sub UNIVERSAL::bind_meth { my ($self, $meth, @args) = @_; my $func = $self->can($meth); if (defined($func)) { return sub {$func->($self, @args, @_)}; } else { return undef; } }
And now you can curry a method, and curry a few arguments as well while you are at currying favour. And I still get the can that I know and like.

Replies are listed 'Best First'.
Re^2: Why isn't ->can() curried?
by diotalevi (Canon) on Jan 20, 2003 at 19:00 UTC

    This is what comes of spending time with other languages. *grin* In this case it's E which has a home page at http://www.erights.org. It had never occured to me that people would want to compare the code references from ->can. When is that useful?


    Seeking Green geeks in Minnesota

      One use is to verify that a subclass has actually implemented an abstract interface.

        Ah! And I'd previously thought that wasn't detectable. Son in the guise of one thought you've answered something else I didn't know I was asking about! *grin*


        Seeking Green geeks in Minnesota