the good news is that I understand what causes the problem. The bad news
is that it I don't have a solution yet.
The trouble is that you can't really call methods on roles; roles are
rather abstract things, and if you try to call a method on a role, Perl
6 automatically creates a class for you, with the same name as the role.
We call this process "punning".
Calling R.^can($methodname) causes punning, and the punned class doesn't
implement the stubbed method. Thus the error message.
Knowing that, one could just inspect the role's method table instead of
calling .^can. However that's not so easy, because roles come in groups.
Roles can be parametric, and multiple roles of the same name can be
parameterized by different signatures, and applying a role to a class
(possibly with a list of arguments) selects a candidate role, not just a
single role candidate.
So far I haven't seen any method in the ParametricRoleGroupHOW that
gives me a list of those candidates, or a of methods. So I don't know
how to emulate .^can.
I'll see if anybody in #perl6 (IRC) has a good idea...
On 19.05.2014 14:52, Kamil Kułaga wrote:
> Hi Moritz,
> I've tried to adapt Your gist to something else but I've realized that
> it does not work with stubs. Is it possible to bypass problem with
> incomplete R?
> I feel very inspired :)
> On Fri, May 16, 2014 at 10:44 AM, Moritz Lenz <mor...@faui2k3.org> wrote:
>> Hi Kamil,
>> On 05/15/2014 07:48 PM, Kamil Kułaga wrote:
>>> Is there any ordinary way (not something like getting list of methods
>>> from base class) to ensure we are overriding method?
>>> Java has @Override annotation that that causes compilation error if
>>> method is not necessary for Interface(Role). It is very handy if class
>>> does many of them and someone cuts out deprecated method and there is
>>> no reason to implement them any longer.
>> Not by default, but the meta programming facilities make it just a small
>> exercise to implement such a thing in user space.
>> I've done that in
>> Feel inspired :-)