On Wed, Jul 06, 2005 at 12:58:44 +0100, Piers Cawley wrote:
> Then write yourself a module, call it 'multiplicity' say, which would allow
> you
> to say
>
> use multiplicity;
>
> sub foo (...) {...} # foo is a multimethod, even if there's already a
> 'SMD'
> # foo in existence.
>
> It shouldn't even be that hard, just macroize sub/method/whatever to become
> multis that first check if there's already a singly dispatched sub with the
> same name and promoting to multi status if possible.
>
> Of course, if you use something like that, you're taking the risks on your own
> head, but you knew that as soon as you typed 'use multiplicity'.
>
> The important thing is that the dispatch and reflection system should be
> flexible enough to allow you to write something like this.The issue is cultural, not technical. If people expect SMD, use it, rely on it, MMD is just another esotheric feature. Newbies' code will not exploit. Most of CPAN will not be ready for it. I won't write me such a module because it'll be more headache than benefit - explaining to everyone that in my code I like everything MMD. What I'm claiming is that MMD like behavior should be the norm. When it's not appended with true multiness, it's functionally identical to SMD. The issue is that extending another person's module with a multimethod, and using type/parameter dispatch in order to help code evolve better over time will never be a "good" or normal thing to do if it feels kludgy. My claim is that it doesn't need to feel kludgy. A macro library kludging over a kludge is twice as kludgy as it was before. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me does a karate-chop-flip: neeyah!!!!!!!!!!!!!!
pgpP1GcZ9euDb.pgp
Description: PGP signature
