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.