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.