Larry Wall wrote:
Depends on whether the user is actually expecting equal MMD there,
or tie-breaking between multi methods within the particular class.
My gut-level feeling is that they expect the latter.
With combined .method and method: syntax we also could have a nice
top priority or innermost single invocant that possibly redispatches
outwards. With sufficient type information the selection might already
happen at compile time.
: > ... However, that being
: > said, there's enough flexibility in the FETCH/STORE proxy that you
: > could "defactor" the identification code out to the various handlers
: > and get the same benefit.
:
: Well, isn't the "defactorized" code just a bunch of multi subs?
I don't think of it that way. Considering the code is bound to a
particular proxy object before it is ever called, it seems to fall
even more into the category of multi method rather than multi sub.
This is one of the big flying leaps that Perl 6 is trying to take.
We've had lots of MMD implementations in the world, but Perl 6 is
attempting to make that orthogonal to all the other scoping mechanisms,
I agree. We have:
1) backwards/forward along the call chain
2) outwards/inwards for lexical scopes
3) specificity on the (ordered) set of invocant arguments
including lexical scopes and class scopes. If there's prior art,
I'm not aware of it.
The Cecil people have done some research under which pre-conditions
a global MMD can be broken up into modularized MMD without loosing
type safety. This limits Perl6's innovation to providing a nice
syntax for it and making type safety optional---or better two ends
of a spectrum. Actually I hope type safety is not really optional but
deferred to runtime exceptions or undefined values that eventually
result in an exception.
I suppose the non-brain-burning view of it is
that any extra lexical or class scope dimension just turns into an
extra absolute constraint on which subset of the global subs of that
short name can be called.
Well, isn't MMD just another non-local control flow exception?
At the first level the object's vtable is some kind of pre-calculated
dispatch. From there on it goes outwards through lexical dispatchers.
--
TSa (Thomas Sandlaß)
