Damian Conway <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>>>Multimethods don't belong to classes; they mediate interactions
>>>*between* classes.
>> Will the 'is multi' actually be necessary? Just curious.
>
> That's still being discussed. *Something* is necessary. But it may
> be that, instead of:
>
> sub handle (Window $w, Event $e, Mode $m) is multi {...}
>
> one will write:
>
> sub handle (Window $w: Event $e: Mode $m:) {...}
>
> That is, if it's a C<sub> (or a method, for that matter) and
> you specify that it has multiple invocants, then it's a multimethod.
>
> The advantage, of course, is that this potential syntax confers much
> finer control over which parameters participate in the multiple
> dispatch. For example, if that had been:
>
> sub handle (Window $w: Event $e, Mode $m:) {...}
>
> then the dispatch would only be polymorphic with respect to
> $w and $m.
>
> The *disadvantage* of this syntax is that it confers much finer
> control over which parameters participate in the multiple dispatch --
> which may make it harder to achieve predictable dispatch behaviours
> for specific multimethods.
>
> Another disadvantage is that it's easier to miss those trailing colons
> (or confuse them with semicolons), whereas an explicit C<is multi> is a
> much clearer signal of intent.
I really don't like that fine grained syntax I'm afraid. And I'm not
entirely sure you actually gain anything from it do you?
Another option,
sub handle (Window $w, Event $e, Mode $m) is dispatched($w, $m) {...}
is explicit, but disgusting.
I also find myself wondering if functions called with:
$foo.bar($baz)
should be *required* to be singly dispatched on $foo and saying that
mulitply dispatched functions/generics/whatever should look like
normal function calls:
bar($foo, $baz); # May be multiply dispatched
But I can't begin to offer reasons for this beyond a vague gut
feeling.
