Trey Harris wrote:
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but
what immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of
the points, and the only point that matters when we're talking about
multis of a single invocant) is that arguments are not bound to a
single type. So at first gloss, having a single prototype in the core
for all same-named multis as in your proposal seems to defeat that
use, because it does constrain arguments to a single type.
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The really
interesting thing is to match signature shapes, not types. That is, max
doesn't take two positional arguments, and a max that does is probably
doing something that users of max will be shocked by. To this end, a
programmer of a library *can* issue an assertion: all implementations of
max will take one (no type specified) positional parameter and any
number of adverbial named parameters (again, no type specified).
Notice that I keep saying "no type specified", when in reality, us Perl
6 programmers know that parameters default to type Any (it is Any now,
right?) I don't see value in protos taking this into account. If there
is value, then I'll bow to superior Perl 6 mojo on the part of whoever
can point it out.
Remember that this is NOT part of the MMD system. Once a multi is
declared, and passes any existing protos, the proto no longer has any
relevance, and is never consulted for any MMD dispatch. It is forgotten
(unless a new multi is defined later).
Does that help to remove any concerns? Adding in types is fine, and I
have no problem with it, but adding in types should probably not be
something done in core modules without heavy thought.
In other words, to use your proposal, "our proto moose (Moose $x:)"
should assert not just that all calls to the multi moose will have an
invocant that does Moose, but also that all objects of type Moose will
work with a call to the multi moose. That may have been implicit in
your proposal, but I wanted to make it explicit.
If you specify such types, OK, that seems fair. Side point: "the multi
moose" is a pretty darned funny turn of phrase ;)
All that said, the globalness of multis does concern me because of the
possibility of name collision, especially in big systems involving
multis from many sources. Your proposal would at least make an
attempt to define a multi not type-conformant with a core prototype
throw a compile-time error, rather than mysterious behavior at runtime
when an unexpected multi gets dispatched.
Say "signature-conformant" there, and I'm in full agreement.
