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.
On Fri, Jun 27, 2014 at 3:25 PM, Timo Paulssen <t...@wakelift.de> wrote:
> On 27/06/14 10:07, Kamil Kułaga wrote:
>>
>> 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 :)
>>
>
> 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
--
Pozdrawiam
Kamil Kułaga
