[23:55:42] rn: class A { }; my $a= A.new( foo => 1 ); $a # shouldn't this complain about trying to initialize a non-existing attribute?
[23:55:44] <+camelia> rakudo 802574, niecza v24-37-gf9c8fc2: ( no output )
This came up during my work in the masakism class
Followup discussion:
[23:26:34] wrt to 117829: perhaps this should at least be activated during tests?
[23:27:15] so that "new" complaints about excess named parameters?
[23:27:33] census (435335b7@gateway/web/freenode/ip.67.83.53.183) left IRC. (Ping timeout: 245 seconds)
[23:28:11] n: class Foo { has $.bar }; my Foo $a .= new( bar => 1, baz => 2 )
[23:28:12] <+camelia> niecza v24-37-gf9c8fc2: OUTPUT«Potential difficulties: $a is declared but not used at /tmp/bY2D_twm2f line 1:------> [32mclass Foo { has $.bar }; my Foo [33m⏏[31m$a .= new( bar => 1, baz => 2 )[0m»
[23:28:24] n: class Foo { has $.bar }; my Foo $a .= new( bar => 1, baz => 2 ); $a
[23:28:26] <+camelia> niecza v24-37-gf9c8fc2: ( no output )
[23:28:46] hmmm.. I seem to recall Niecza complaining about excess named parameters
[23:28:54] rn: say :foo
[23:28:56] <+camelia> niecza v24-37-gf9c8fc2: OUTPUT«Unhandled exception: Excess arguments to gistcat, unused named foo at /home/p6eval/niecza/lib/CORE.setting line 0 (gistcat @ 1)  at /home/p6eval/niecza/lib/CORE.setting line 1366 (say @ 7)  at /tmp/luJiMs62qw line 1 (mainline @ 3)  at /home/p6eval/…
[23:28:57] <+camelia> ..rakudo c66c42: OUTPUT«»
[23:29:04] I guess not always
[23:29:05] #117829 should probably not be an RT ticket, because it's not a Rakudo bug, as far as I know.
[23:29:14] yeah, it's a specbug.
[23:29:19] well, not even a specbug.
[23:29:30] rakudo is performing as specced.
[23:29:33] It's not automatically a bug. It's a request to reconsider an aspect of the design.
[23:29:38] right.
[23:29:42] indeed
[23:29:43] Anyway, part of keeping RT to a sane size is not having such things in it.
[23:29:58] so where would this live then?
[23:30:02] http://github.com/perl6/specs/issues
[23:30:05] (We used to have some [spec] tickets there, but they got moved to GitHub issues in the spec repo)
[23:30:31] tgt (~tgt@cpc1-aztw25-2-0-cust6.aztw.cable.virginmedia.com) joined the channel.
[23:30:31] skids (~bri@charon.clarku.edu) left IRC. (Ping timeout: 264 seconds)
[23:30:35] I'm looking at the Mu.new and Mu.BUILD code to see how hard it would be to manage.
[23:31:08] (then by all means close it in RT, I'll create in issue in spec)
[23:31:13] an
[23:32:09] pmichaud: Trouble is knowing when to complain.
[23:32:25] I would think it'd have to be at the end of BUILDALL
[23:32:41] if anything in %attrinit didn't get used, then complain about it.
[23:33:06] (I agree it's potentially a lot of checking and overhead)
[23:33:23] Yeah :(
[23:33:26] indeed. It wouldn't make things faster
[23:33:31] And it's a hot path.
[23:33:38] agree with that
[23:33:48] The code is already, um, interesting 'cus of things I did to try and cope with that.
[23:33:50] therefore I was more thinking about a compile time only
[23:33:57] check
[23:34:13] you don't know what is being .newed at compile time, though.
[23:34:20] We don't tend to do analysis of any methody stuff at compile time.
[23:34:31] Because it's too late bound / overridable.
[23:35:08] We go wild on stuff in lexical scopes after CHECK time, but method calls are more, "can't touch this".
[23:35:11] my Foo $obj = (Bool.pick ?? Foo !! Bar).new( @args )
[23:36:00] I was more thinking about the case of my Foo $obj .= new( foo => 1, bar => 2 )
[23:36:11] where bar is not an attribute
[23:36:24] so, only in a declaration.
[23:36:30] But what if there's a new that knows what to do with it, or a BUILD that knows how to process those things?
[23:36:44] indeed...
[23:36:53] so, only in a declaration for a class that hasn't overridden .new, .BUILD, .BUILDALL, or .bless :-)
[23:37:03] or .create
[23:37:04] I was thinking of a pragma that would lexically wrap .new ?
[23:37:08] er, .CREATE
[23:37:19] Lex...what? It's a method. :)
[23:37:44] wrap the candidate(s) ?
[23:38:29] you can .wrap methods, no?
[23:38:33] Wrapping is (a) not that cheap already, and (b) frustrates optimizations.
[23:38:56] I see it more as a "use diagnostics" type of thing
[23:39:03] lizmat: You can. You can wrap subs, but you have to put a "use soft" pragma in place. In return, the compiler will refuse to do any inlining.
[23:39:07] to be used when you're willing to pay the price
[23:39:31] whatever checking we're going to do, really ought to be in the build process directly. It could be something that is activated only by a lexical pragma.
[23:39:39] nod
[23:39:41] (at a penalty, of course)
[23:40:11] indeed...
[23:40:22] I mean, there's nothing that is stopping you writing a role, sticking it in a module and applying it to your classes. The role provides an alternative new or BUILD or whatever that gives the semantics you wish.
[23:40:24] anyway, it's worth filing a spec ticket for.
[23:40:50] which is what I will do… and then the RT ticket can be closed or deleted or whatever :-)
[23:40:58] Then if you want a "do it to all classes I declare in this scope", just write a meta-class override that adds the role by default to any class declaration :)
[23:41:15] "just write a meta-class override"
[23:41:16] All the ingredients should be there for such a pragma to be written in Perl 6 already. :)
[23:41:37] :-D
[23:41:50] jnthn: indeed, and it would be something I could put on my list
[23:41:52] ;-)
[23:41:57] tgt (~tgt@cpc1-aztw25-2-0-cust6.aztw.cable.virginmedia.com) left IRC. (Quit: Computer has gone to sleep.)
[23:42:28] pmichaud: Well, Grammar::Tracer "just" does that ;)
[23:43:34] lizmat: Well, it also allows prototyping this out of core, meaning if it works out Totally Awesome there's a concrete thing to play with and consider spec'ing.
[23:43:47] indeed :-)
4 May 2013 23:03Z lizmat: you want to subclass ClassHOW, I expect. You then write a role with the new functionality you want in, and then arrange for it to be mixed in to every class automatically (easiest is probably method compose($obj) { self.add_role($obj, YourRolewithNewIn); nextsame; }
lizmat
commented
11 years ago
Original RT ticket 117829:
[23:55:42] rn: class A { }; my $a= A.new( foo => 1 ); $a # shouldn't this complain about trying to initialize a non-existing attribute?
[23:55:44] <+camelia> rakudo 802574, niecza v24-37-gf9c8fc2: ( no output )
This came up during my work in the masakism class
Followup discussion: [23:26:34] wrt to 117829: perhaps this should at least be activated during tests?
[23:27:15] so that "new" complaints about excess named parameters?
[23:27:33] census (435335b7@gateway/web/freenode/ip.67.83.53.183) left IRC. (Ping timeout: 245 seconds)
[23:28:11] n: class Foo { has $.bar }; my Foo $a .= new( bar => 1, baz => 2 )
[23:28:12] <+camelia> niecza v24-37-gf9c8fc2: OUTPUT«Potential difficulties: $a is declared but not used at /tmp/bY2D_twm2f line 1:------> [32mclass Foo { has $.bar }; my Foo [33m⏏[31m$a .= new( bar => 1, baz => 2 )[0m»
[23:28:24] n: class Foo { has $.bar }; my Foo $a .= new( bar => 1, baz => 2 ); $a
[23:28:26] <+camelia> niecza v24-37-gf9c8fc2: ( no output )
[23:28:46] hmmm.. I seem to recall Niecza complaining about excess named parameters
[23:28:54] rn: say :foo
[23:28:56] <+camelia> niecza v24-37-gf9c8fc2: OUTPUT«Unhandled exception: Excess arguments to gistcat, unused named foo at /home/p6eval/niecza/lib/CORE.setting line 0 (gistcat @ 1)  at /home/p6eval/niecza/lib/CORE.setting line 1366 (say @ 7)  at /tmp/luJiMs62qw line 1 (mainline @ 3)  at /home/p6eval/…
[23:28:57] <+camelia> ..rakudo c66c42: OUTPUT«»
[23:29:04] I guess not always
[23:29:05] #117829 should probably not be an RT ticket, because it's not a Rakudo bug, as far as I know.
[23:29:14] yeah, it's a specbug.
[23:29:19] well, not even a specbug.
[23:29:30] rakudo is performing as specced.
[23:29:33] It's not automatically a bug. It's a request to reconsider an aspect of the design.
[23:29:38] right.
[23:29:42] indeed
[23:29:43] Anyway, part of keeping RT to a sane size is not having such things in it.
[23:29:58] so where would this live then?
[23:30:02] http://github.com/perl6/specs/issues
[23:30:05] (We used to have some [spec] tickets there, but they got moved to GitHub issues in the spec repo)
[23:30:31] tgt (~tgt@cpc1-aztw25-2-0-cust6.aztw.cable.virginmedia.com) joined the channel.
[23:30:31] skids (~bri@charon.clarku.edu) left IRC. (Ping timeout: 264 seconds)
[23:30:35] I'm looking at the Mu.new and Mu.BUILD code to see how hard it would be to manage.
[23:31:08] (then by all means close it in RT, I'll create in issue in spec)
[23:31:13] an
[23:32:09] pmichaud: Trouble is knowing when to complain.
[23:32:25] I would think it'd have to be at the end of BUILDALL
[23:32:41] if anything in %attrinit didn't get used, then complain about it.
[23:33:06] (I agree it's potentially a lot of checking and overhead)
[23:33:23] Yeah :(
[23:33:26] indeed. It wouldn't make things faster
[23:33:31] And it's a hot path.
[23:33:38] agree with that
[23:33:48] The code is already, um, interesting 'cus of things I did to try and cope with that.
[23:33:50] therefore I was more thinking about a compile time only
[23:33:57] check
[23:34:13] you don't know what is being .newed at compile time, though.
[23:34:20] We don't tend to do analysis of any methody stuff at compile time.
[23:34:31] Because it's too late bound / overridable.
[23:35:08] We go wild on stuff in lexical scopes after CHECK time, but method calls are more, "can't touch this".
[23:35:11] my Foo $obj = (Bool.pick ?? Foo !! Bar).new( @args )
[23:36:00] I was more thinking about the case of my Foo $obj .= new( foo => 1, bar => 2 )
[23:36:11] where bar is not an attribute
[23:36:24] so, only in a declaration.
[23:36:30] But what if there's a new that knows what to do with it, or a BUILD that knows how to process those things?
[23:36:44] indeed...
[23:36:53] so, only in a declaration for a class that hasn't overridden .new, .BUILD, .BUILDALL, or .bless :-)
[23:37:03] or .create
[23:37:04] I was thinking of a pragma that would lexically wrap .new ?
[23:37:08] er, .CREATE
[23:37:19] Lex...what? It's a method. :)
[23:37:44] wrap the candidate(s) ?
[23:38:29] you can .wrap methods, no?
[23:38:33] Wrapping is (a) not that cheap already, and (b) frustrates optimizations.
[23:38:56] I see it more as a "use diagnostics" type of thing
[23:39:03] lizmat: You can. You can wrap subs, but you have to put a "use soft" pragma in place. In return, the compiler will refuse to do any inlining.
[23:39:07] to be used when you're willing to pay the price
[23:39:31] whatever checking we're going to do, really ought to be in the build process directly. It could be something that is activated only by a lexical pragma.
[23:39:39] nod
[23:39:41] (at a penalty, of course)
[23:40:11] indeed...
[23:40:22] I mean, there's nothing that is stopping you writing a role, sticking it in a module and applying it to your classes. The role provides an alternative new or BUILD or whatever that gives the semantics you wish.
[23:40:24] anyway, it's worth filing a spec ticket for.
[23:40:50] which is what I will do… and then the RT ticket can be closed or deleted or whatever :-)
[23:40:58] Then if you want a "do it to all classes I declare in this scope", just write a meta-class override that adds the role by default to any class declaration :)
[23:41:15] "just write a meta-class override"
[23:41:16] All the ingredients should be there for such a pragma to be written in Perl 6 already. :)
[23:41:37] :-D
[23:41:50] jnthn: indeed, and it would be something I could put on my list
[23:41:52] ;-)
[23:41:57] tgt (~tgt@cpc1-aztw25-2-0-cust6.aztw.cable.virginmedia.com) left IRC. (Quit: Computer has gone to sleep.)
[23:42:28] pmichaud: Well, Grammar::Tracer "just" does that ;)
[23:43:34] lizmat: Well, it also allows prototyping this out of core, meaning if it works out Totally Awesome there's a concrete thing to play with and consider spec'ing.
[23:43:47] indeed :-)