On 7/8/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I have a draft of a proposition for what I think is proper MMD
> dispatching order:
>
> http://svn.openfoundry.org/pugs/docs/mmd_match_order.txt
--
> Order of definition tie breaking:
>
> Two signatures defined in the same file:
>
> the one EARLIER in the file wins
>
> Two signatures defined in a different file:
>
> the one defined LATER in the file wins
Hmm. I wonder if we should just make the later ones win in all cases.
Generally when I structure code, I find it most natural to go from
general to specific. If we're going to make a choice for the user
(something we usually avoid), we might as well go with the one that I
would pick :-)
I like the idea of your tree of match order, I just don't like the
tree itself too much. If we're going to reorder things for the user,
it does need to happen in a predictable way, even if it's not correct
100% of the time. I find your tree to be pretty complex (that could
be because I don't understand the reasoning for the ordering
decisions). I'd prefer something more like:
1. Constants
2. Junctions / Ranges
3. Regexes
4. Codeblocks
Where none of them is recursively decended into for matching. That
particular order has no special significance, it just felt natural.
I'm just pointing out that it should be simple[1].
Still, I very much agree with your desire to be able to extend someone
else's interface, which we can solve by messing with the tiebreaking
order.
Luke
[1] That is also my complaint about the Manhattan metric for
multimethod resolution: it is only simple and predictable when you
have the whole class heirarchy in your head.
