On Fri, Apr 11, 2003 at 11:22:43AM -0700, Paul wrote:
: > Multimethods can have multiple invocants. A colon terminates the list
: > of invocants, so if there is no colon, all parameters are considered
: > invocants. Only invocants participate in multimethod dispatch. Only
: > the first invocant is bound to $_.
:
: Which pretty much explains all of it, I think.
:
: multi foo ($me, Int $i: *@x) {...} # version 1
: multi foo ($me, String @s: *%x) {...} # version 2
: multi foo ($me, $a, @b: *@x) {...} # version 3
:
: These would dispatch based on their required args, since all the
: required args happen to be invocants.
:
: $o->foo(1); # calls version 1
: $o->foo(qw/ this calls version 2 /);
: $o->foo($x,@y); # calls version 3
:
: right?
Er, not quite. First, you want . rather than ->. Next, you don't
want . at all, unless you want to try single dispatch first and then
fall back on multimethod dispatch. You typically call a multimethod
as if it were a sub:
foo($o, 1); # calls version 1
foo($o, qw/ this calls version 2 /);
foo($o, $x,@y); # calls version 3
Also, the string type is Str, not String. Whether #2 works may
depend on whether the list returned by qw// is marked as type Str.
If not, it might be ambiguous. I don't know to what extent multimethod
dispatch should peek inside random scalars and try to guess whether
they're integers or strings.
Larry
Thread Previous
|
Thread Next