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
Values may be compiled into where clauses which are eventually just
a big given/when behind the scenes, but the order in which they are
checked must be integrated with type checking, and must be sorted to
make sense.
If you cannot define a more particular case of a method in order to
optimize for:
* speed
* simplicity
then you lose on a lot of what makes MMD a useful tool for post-oop.
In code which was preplanned for MMD, that was properly ordered, mmd
is useful as a subset of it's behavior - it's just pattern matching.
This is nice, but has none of the extensibility that MMD can offer
if done differently.
On Fri, Jul 08, 2005 at 12:18:51 +0300, Yuval Kogman wrote:
> On Fri, Jul 08, 2005 at 08:50:49 +0000, Luke Palmer wrote:
>
> > Not unless you want to write the Halting engine that determines that 3
> > is in fact more specific that 2..10. It's based on definition order,
> > so that if you have dependencies in you condition (which you
> > oughtn't), you'd better define the multis together to get well-defined
> > semantics.
>
> That seriously sucks.
>
> Multis rock because they let you append to an interface from your
> perspective.
>
> If it's just a pretty form of casing, then we aren't gaining
> anything, IMHO.
>
> --
> () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
> /\ kung foo master: /me groks YAML like the grasshopper: neeyah!!!!!!
>
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me sneaks up from another MIME part: neeyah!!!!!
pgp0vv9Yu8MpD.pgp
Description: PGP signature
