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.

So we're still considering the matter.

Damian




Reply via email to