Diffrence between is and does in scope of overriding multi methods

[Kamil Kułaga]

Hi,

I would like to ask for help in understanding difference between this code:

use v6;

role X {
multi method xyz(Any $a) {say "Class X"}
}

class Y does X {
multi method xyz(Any $a) {say "Class Y"}
}

say Y.new.xyz(1);

$ perl6 tst.pl
Ambiguous call to 'xyz'; these signatures all match:
:(Y: Any $a, *%_)
:(Y: Any $a, *%_)
in block at tst.pl:26

And this code:
use v6;

class X {
multi method xyz(Any $a) {say "Class X"}
}

class Y is X {
multi method xyz(Any $a) {say "Class Y"}
}

say Y.new.xyz(1);

$ perl6 tst.pl
Class Y
True

It is hard to google such common words like is and does :)

--
Pozdrawiam

Kamil Kułaga

[Timo Paulssen]

Hey Kamil,

What happens when you "does" a role in a class, you "mix in" all the
methods at the "same level", basically as if you had copy-pasted the
method declarations over. That's why you get the error that the call to
xyz is ambiguous.

When you "is" a class, you derive from it. That's why the multi method
X::xyz gets "overwritten" by Y::xyz, as the signature is identical.

At least that's my understanding.

Btw, you can also "is" a role, in which case it will get "punned" into a
class. That operation is equivalent to declaring a class with an empty
body that "does" the given role. So in the upper example, with role X
and class Y, you could "is X" and get the same behavior as in the lower
example.

Hope to help (and hope what I wrote is actually accurate)
- Timo

[Elizabeth Mattijsen]

FWIW, I’m not sure why the first case is actually a problem. I would expect this error if both X and Y were a role composed into a class Z.


Liz

[Kamil Kułaga]

Hi Timo,

After I read your explanation and now it is even logical to use role
punning in my app. In most cases I don't want to override this default
behavior of method xyz but I would like to add new specific one. Only
one class does opposite so it should be subclass of a role.

--
Pozdrawiam

Kamil Kułaga