On Sat Sep 05 07:47:24 2015, dakkar wrote:
> Given this code::
>
> {
> class Foo { has $.x }
>
> multi sub infix:<eqv>(Foo $a, Foo $b) {
> say "won't get called";
> $a.x eqv $b.x
> }
> }
>
> multi sub infix:<eqv>(Foo $a, Foo $b) {
> say "will get called";
> $a.x eqv $b.x
> }
>
> my @a = Foo.new(:x(1));
> my @b = Foo.new(:x(1));
>
> say @a[0] eqv @b[0];
> say @a eqv @b;
>
> the output is::
>
> will get called
> True
> False
>
> because:
>
> - the first ``eqv`` definition is not visible to any of the calls
> - the second ``eqv`` definition is not visible to the
> ``infix:<eqv>(@a,@b)`` in the setting
>
This is correct; multis are lexically scoped.
> This means that:
>
> - ``eqv``s defined in other packages are never used
Well, they are in the lexical scope of the package.
> - adding a ``eqv`` for users' types is not very useful, since they
> won't be called most of the time
>
Typically you'll be writing such types in a module; adding "is export" to the
eqv multi candidates you declare will export them, and then they'll be
available to anyone importing your type. And if you're in a single file, you
can still write them inside of a package and then "import" that package to get
them into scope.
> Should there be some mechanism like ``ACCEPTS`` to make ``eqv`` more
> useful?
>
No, given then you'd be able to apply this argument to every other operator in
the language you might consider overloading.
> Should there be a mechanism to add ``multi`` candidates dynamically?
>
We have to know the list of multi-candidates at CHECK time; since export/import
happen at BEGIN time, then that's enough "static dynamism" for this case.
Hope this helps,
/jnthn
