develooper Front page | perl.perl6.language | Postings from July 2006

Re: Methods vs. Subs

Thread Previous
Larry Wall
July 8, 2006 09:58
Re: Methods vs. Subs
Message ID:
On Sat, Jul 08, 2006 at 07:42:06AM -0700, Jonathan Lang wrote:
: Is there anything that you can do with a sub (first parameter being
: some sort of object) that you cannot do with a method?  Frex, given:
:  multi method my_method($invocant:);
: would
:  &topical_call := &my_method.assuming :invocant<$_>;
: be legal?

Yes, it's certainly legal, but it's not quite the same semantics.
A sub guarantees at compile time exactly which routine is going to
be called.  Your example would need a ::= to do that.  But even with
that it doesn't really guarantee which my_method you're going to get,
in the sense that .assuming is going to have to do a partial method
dispatch, and which method it finds will depend on the value of $_.
Furthermore, ::= would force that to mean the compile-time value of
$_, which is probably not what you want anyway.

As far as I can figure, there's no way of defining topical_call such
that it knows to .assume $_ as its invocant without actually evaluating
$_ at the time .assuming is called, since .assuming doesn't merely
set the default; it's a partial dispatch, and throws away the assumed
parameter slot entirely from the viewpoint of the subsequent caller.
It may well have to keep track of the slot for implementation,
however--as a partial dispatch, &topical_call may in fact represent a
set of remaining candidates to be multi dispatched, and merely setting
one parameter with .assuming shouldn't imply that that's the entire
eventual parameter list.  That is, it mustn't assume that the supplied
parameters are delimited with semicolons in the receiving signature.
So for purposes of implementation, it does behave merely like a default.
Go figure...


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About