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

Errors augmenting `Any` #2356

Open
mkrull opened this Issue Oct 9, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@mkrull
Copy link

mkrull commented Oct 9, 2018

The Problem

It is not possible to augment classes and have the new method available in deeper in the tree.

case 1

use v6.c;

use MONKEY-TYPING;

augment class Any {
    method show0 { self.say }}

<hello world>.show0;

case 2

use v6.c;

use MONKEY-TYPING;

augment class Any {
    method show0 { self.say }}

augment class List {
    method show1 { self.say }}

<hello world>.show0;
<hello world>.show1;

Expected Behavior

Output of (hello world)

Actual Behavior

An error gets thrown:

No such method 'show0' for invocant of type 'List'. Did you mean 'show0'?
  in block <unit> at showcase.p6 line 9

Case 2 produces the expected

(hello world)
(hello world)

Steps to Reproduce

Full output where showcase.p6 is a file containing the code of case 1 above:

> perl6 --ll-exception showcase.p6
No such method 'show0' for invocant of type 'List'. Did you mean 'show0'?
   at SETTING::src/core/Exception.pm6:57  (/home/matthias/.rakudobrew/moar-2018.08/install/share/perl6/runtime/CORE.setting.moarvm:throw)
 from SETTING::src/core/Exception.pm6:2744  (/home/matthias/.rakudobrew/moar-2018.08/install/share/perl6/runtime/CORE.setting.moarvm:)
 from gen/moar/BOOTSTRAP.nqp:3736  (/home/matthias/.rakudobrew/moar-2018.08/install/share/nqp/lib/Perl6/BOOTSTRAP.moarvm:)
 from showcase.p6:9  (<ephemeral file>:<unit>)
 from showcase.p6:1  (<ephemeral file>:<unit-outer>)
 from gen/moar/stage2/NQPHLL.nqp:1567  (/home/matthias/.rakudobrew/moar-2018.08/install/share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:1806  (/home/matthias/.rakudobrew/moar-2018.08/install/share/nqp/lib/NQPHLL.moarvm:evalfiles)
 from gen/moar/stage2/NQPHLL.nqp:1729  (/home/matthias/.rakudobrew/moar-2018.08/install/share/nqp/lib/NQPHLL.moarvm:command_eval)
 from src/Perl6/Compiler.nqp:42  (/home/matthias/.rakudobrew/moar-2018.08/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:1655  (/home/matthias/.rakudobrew/moar-2018.08/install/share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/main.nqp:47  (/home/matthias/.rakudobrew/moar-2018.08/install/share/perl6/runtime/perl6.moarvm:MAIN)
 from gen/moar/main.nqp:38  (/home/matthias/.rakudobrew/moar-2018.08/install/share/perl6/runtime/perl6.moarvm:<mainline>)
 from <unknown>:1  (/home/matthias/.rakudobrew/moar-2018.08/install/share/perl6/runtime/perl6.moarvm:<main>)
 from <unknown>:1  (/home/matthias/.rakudobrew/moar-2018.08/install/share/perl6/runtime/perl6.moarvm:<entry>)

Environment

  • Operating system: Ubuntu 18.04
  • Compiler version (perl6 -v): This is Rakudo version 2018.08 built on MoarVM version 2018.08
@mkrull

This comment has been minimized.

@zoffixznet

This comment has been minimized.

Copy link
Contributor

zoffixznet commented Oct 9, 2018

That's a known limitation. The class doesn't know who its kids are. You need to recompose the kids to get the augmented methods, which in the second case happens 'cause of your augment:

use v6.c;

use MONKEY-TYPING;

augment class Any {
    method show0 { self.say }}

List.^compose;

<hello world>.show0; # OUTPUT: (hello world)
@mkrull

This comment has been minimized.

Copy link

mkrull commented Oct 9, 2018

I see. My assumption was it would be enough the child knows who the parents are.

Will using .^compose be required looking forward or is that the intended design?

At least the error message does not make much sense 🤔

@jnthn

This comment has been minimized.

Copy link
Member

jnthn commented Oct 9, 2018

I see. My assumption was it would be enough the child knows who the parents are.

It's due to the current approach to method caching, the current scheme needing an explicit flush of the cache built up in the child. It'll be fixed in the future, though more likely on a "couple of years" timescale rather than a "couple of weeks" one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment