Joseph Brenner wrote:
> And now Jonathan Worthington has announced that the new
> Multi-dispatch mechanism is done... any bets on whether
> any of this behavior will change?
I don't see any change in this behavior using a fresh build from github.
Like I was saying:
> If the two [multis] are defined in different modules I suspect you
> could get some strange behavior that would be hard to debug.
> It's not always immediately obvious in what order two things were
> defined.
Here's an example, scattered across four files, which
I've also pus
I'm not entirely sure what you're getting at with that example.
I was particularly interested in cases where there's some
ambiguity in multi-dispatch for particular values, where there's
some overlapping coverage between the prototypes.
Just for the hell of it, I'll stick another example at
the bo
On Sat, Sep 25, 2021 at 2:30 PM Joseph Brenner wrote:
> > Since subsets are just code it would be difficult to impossible
> > to determine all of the ones that can match without actually
> > running them all. This would slow down every call that uses
> > multiple subsets.
>
> I can see how there
> Since subsets are just code it would be difficult to impossible
> to determine all of the ones that can match without actually
> running them all. This would slow down every call that uses
> multiple subsets.
I can see how there would be a big performance hit, but I haven't
yet turned up any ref
This is intended behavior.
Since subsets are just code it would be difficult to impossible to
determine all of the ones that can match without actually running them all.
This would slow down every call that uses multiple subsets.
By most narrow candidate, it means by type. All subsets "of" the sa
This code uses multi dispatch with constraints that are ambiguous
in a few cases, because there's some overlap in the lists of
monsters and heroes: 'mothera' and 'godzilla'.
my @monsters = < godzilla mothera ghidora gammera golem
wormface >;
my @heroes = < beowulf bluebeetle be
