No concretization found with role-qualified method call when doing a role from another role

[taboege]

The Problem

Role-qualified method call does not work when my class does a role indirectly, e.g.

role  X        { method f {} }
role  Y does X { method g {} }
class C does Y {}

C.new.Y::g;  # works
C.new.X::f;  # ERROR: No concretization found for X

This way to trigger that error is different, but #2282 is possibly related.

Expected Behavior

Since C.new ~~ X is True, I expect a call to C.new.X::f to succeed.

Actual Behavior

I get the error No concretization found for X.

Tested on Camelia rakudo-moar 7262b4e84.

[taboege]

The documentation claims that C does Y when Y does X should result in the same thing as C does Y does X (where Y isn't required to do X anymore). That is, the above should be equivalent to

role  X               { method f {} }
role  Z               { method g {} }
class C does Z does X {}

C.new.Z::g;  # works
C.new.X::f;  # works too

but as noted, this version does work!

[fecundf]

with roles doing "flat" copying, from class C does Y {} I don't have an expectation that C knows the name "X" - only that C can do all the methods from Y, which includes all the methods that came from X.

role  X        { method f { say "f" } }
role  Y does X { method g { say "g" } }
class C does Y {}

C.new.Y::g;  # works
C.new.Y::f;  # works

With class C does Z does X {} then it would know both the "Z" and "X" names.

True, the documentation for roles did say that class C is the same regardless of how the two roles are applied. To me, the current implementation makes sense- otherwise, a change allowing class C does Y {}; C.new.X::f is allowing "spooky action at a distance" with X as a member of C without ever declaring X in C. The documentation should be clarified, seems like a doc bug to me.

[taboege]

On Tue, 29 Jan 2019, fecundf wrote: with roles doing "flat" copying, from `class C does Y {}` I don't have an expectation that C knows the name "X" - only that C can do all the methods from Y, which includes all the methods that came from X. ``` role X { method f { say "f" } } role Y does X { method g { say "g" } } class C does Y {} C.new.Y::g; # works C.new.Y::f; # works ```

D'oh, I hadn't thought of this, but it makes sense. Revisiting the code that I needed this to be resolved for, I was actually trying to wrap a method `f` from a role `X` inside another role `Y does X`, and have some of my classes do Y, but most others do X, and rely on X in type checks. That idea was fundamentally flawed, I think, because inside the class doing Y, the method f of X that is wrapped by method f of Y wouldn't even exist anymore. Can you confirm that? So, I'm asking myself now, "why would one need role-qualified method calls at all?" and consider this resolved and will move on to the docs shortly. Thanks for having a look!

With `class C does Z does X {} ` then it would know both the "Z" and "X" names. True, the documentation for roles did say that class C is the same regardless of how the two roles are applied. To me, the current implementation makes sense- otherwise, a change allowing `class C does Y {}; C.new.X::f` is allowing "spooky action at a distance" with X as a member of C without ever declaring X in C. The documentation should be clarified, seems like a doc bug to me.

But wouldn't the same argumentation forbid `C ~~ X` from revealing True, as it currently does? I guess this is why I got on the track of trying to do what I described above. Somehow, my class still knew about X, so why not call f's old implementation from there?

[fecundf]

So, I'm asking myself now, "why would one need role-qualified method calls
at all?" and consider this resolved and will move on to the docs shortly ...
Somehow, my class still knew about X ...

Yes and yes, no need to qualify the method calls with the roles they came from. Only need to do that on name clashes.

And, as you note, it does make sense to preserve the chain of roles so that C ~~ X is True, in your example. Let's try this-

use v6;

role  X        { method f { say "f" } }
role  Y does X { method g { print "g and... "; self.f } }
class C does Y {}

C.new.f;  # works
C.new.g;  # works
say C ~~ X; # says True

Looks good!

why not call f's old implementation from there (X)?

That I can't answer. This came up on a discussion where the same "No concretization" error came up in a different situation, which looks more like a bug. I'm not a perl6 designer, nor an OO whiz, just interested in these details.

[fecundf]

Problem

This ... I think it distills what you were saying about one role wrapping a method from another role, and it has the "No concretization" error.

use v6;

role  X        { method f { say "f" } }
role  Y does X { method f { print "I'm Y wrapping "; self.X::f  }  }
class C does Y {}

C.new.f;  # I'm Y wrapping No concretization found for X

[vrurg]

Fixed since at least 2019.07