Bob Rogers <[EMAIL PROTECTED]> wrote: > From: Leopold Toetsch <[EMAIL PROTECTED]>
> .sub foo multi(Integer, pmc: String) > .param pmc a > .param pmc b > .param pmc c > - try to dispatch on the first two types in the first place > - if there is a tie, consider the type of the 3rd argument > leo > I've only read half of A12 by now, and am still digesting what I've read > (and that may take a while), but the section headed "multi sub * > (tradition multimethods)" seems to say that the dispatcher never > considers anything after the last colon. So perhaps you meant: > .sub foo multi(Integer, pmc: String:) It depends: if the C<multi> just contains the MMD signature my version is fine. > The next question is, what happens if you define a method with the > "long name": > .sub bar multi(Integer, Float: Float) > and I define one with > .sub bar multi(Integer: String, Integer) > That would mean that the "long names" have different "name length" in > this case. It seems to me that can't work, but if A12 rules it out, I > couldn't find it. If the multi sub is called with an Integer argument (or a class derived from Integer) all "bar" methods of these classes are included in the candidate list. The different "long name length" doesn't matter for that. > If this is supposed to work, then how should MMD handle disagreement > about invocant groups? And if the answer is simply to ignore it, and > treat each method independently, doesn't this screw up the distance > metric? The distance to your method will be computed on the first two > values, whereas the distance to mine will be computed on only the first, > so the two distances will be incommensurable, true? Seems so yes. Except, if shorter (not so specific) long names get a penalty. This seems to need clarification from p6l. > TIA, > -- Bob Rogers leo
