HaloO, John M. Dlugosz wrote:
OK, why would someone create those forms in the first place?
I would think they grow like that historically. A five steps long subtyping chain is not particularly extraordinary. Note that multi entries live outside of classes and their single dispatch.
The subtyping relationship could mean either value subset (e.g. integer passed to code that can handle reals) or polymorphic "isa" objects. The implementation should treat the E correctly because of virtual functions on E, even though the code was written for an A.
Yes, but code that specifies to get an A sanely only uses functionality covered by that requirement. E <: A of course means that the A interface works on an E. But a multi method target should be the most specific choice for *all* parameters. Only that guarantees that all relationships amongst the involved types are taken into account up to a *deterministic* level of specificity.
So why write different forms with =related= classes?
Different forms?
I would define operators with the same name around unrelated classes, so I can use that operator with things that don't already know what to do.
If I understand what you say, then you mean homogeneous multis. These can be implemented with single dispatch on the invocant and generic type enforcement for the other parameters. But MMD is about the heterogeneous case! BTW, the types that "already know what to do" must be implemented with the same features as all the others. There are no magic built-ins.
So why are we focusing on the pathalogical cases? That's like saying we should not support division because you could divide by zero.
But we throw an exception just as with a faulty dispatch.
Rather, what is the common typical use? For the bad stuff, "don't do that" and "do this instead". I think the MMD should work well and be tuned for the areas in which it ought to be used, and the above problem analyzed to see what the programmer was really trying to accomplish.
You want a runtime analysis what the programmers might have meant? So Perl 6 requires AI? Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
