Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private methods on roles are too attached to their own invocant type #4443

Closed
p6rt opened this issue Jul 26, 2015 · 4 comments
Closed

Private methods on roles are too attached to their own invocant type #4443

p6rt opened this issue Jul 26, 2015 · 4 comments

Comments

@p6rt
Copy link

p6rt commented Jul 26, 2015

Migrated from rt.perl.org#125694 (status was 'resolved')

Searchable as RT125694$

@p6rt
Copy link
Author

p6rt commented Jul 26, 2015

From @moritz

Related to, but distinct from RT #​125606​:

role A { method !foo(A​:D​:) { say "success!" } };
role B { method !foo { ... }; method bar {self!foo } };
class C does B does A { }

C.new.bar(); # dies with "Stub code executed"

If one puts method bar into class C, it works.

I think it should also work with method bar in role B​: both the public
and the private method are copied into class C, so there is no reason
why self!foo must pick the private method from the same role.

FWIW this is not an optimizer bug; running with --optimize=off produces
the same result. The generated code is basically
C.new.dispatch​:<!>('foo', B), which searches for private methods in role
B, not in class C.

So I guess the code could be changed to generate to calls
.dispatch​:<!>('foo', C),
but I have no idea how to find the correct type. Maybe (in pseudo-code)​:

if $type.^is-role {
  $type = self.^mro.first($type)
}

@p6rt
Copy link
Author

p6rt commented Jul 30, 2015

From @jnthn

On Sun Jul 26 08​:50​:43 2015, moritz wrote​:

Related to, but distinct from RT #​125606​:

role A { method !foo(A​:D​:) { say "success!" } };
role B { method !foo { ... }; method bar {self!foo } };
class C does B does A { }

C.new.bar(); # dies with "Stub code executed"

If one puts method bar into class C, it works.

I think it should also work with method bar in role B​: both the public
and the private method are copied into class C, so there is no reason
why self!foo must pick the private method from the same role.

FWIW this is not an optimizer bug; running with --optimize=off produces
the same result. The generated code is basically
C.new.dispatch​:<!>('foo', B), which searches for private methods in role
B, not in class C.

So I guess the code could be changed to generate to calls
.dispatch​:<!>('foo', C),
but I have no idea how to find the correct type. Maybe (in pseudo-code)​:

if $type.^is-role {
$type = self.^mro.first($type)
}

You just late-bound it to look up :​:?CLASS when inside of a role. Fixed, and added test in S14-roles/stub.t.

@p6rt
Copy link
Author

p6rt commented Jul 30, 2015

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt closed this as completed Jul 30, 2015
@p6rt
Copy link
Author

p6rt commented Jul 30, 2015

@jnthn - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant