Closed p6rt closed 6 years ago
Code: class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
¦«2015.12»: (bar)
¦«2016.06»: (bar)
¦«2016.12»: (bar)
¦«2017.06»: (bar)
¦«f72be0f130cf»: (bar BUILDALL)
Bisectable points at two relevant commits: First it was BUILDALL_UNDER_CONSTRUCTION after https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc Now it is BUILDALL after https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
I don't know if BUILDALL should be listed or not. My gut feeling says that it shouldn't be, but feel free to argue otherwise. I'm just the messenger.
On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT) \perl6\-bugs\-followup@​perl\.org wrote:
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132283] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=132283 >
Code: class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
¦«2015.12»: (bar)
¦«2016.06»: (bar)
¦«2016.12»: (bar)
¦«2017.06»: (bar)
¦«f72be0f130cf»: (bar BUILDALL)
Bisectable points at two relevant commits: First it was BUILDALL_UNDER_CONSTRUCTION after https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc Now it is BUILDALL after https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
I don't know if BUILDALL should be listed or not. My gut feeling says that it shouldn't be, but feel free to argue otherwise. I'm just the messenger.
Well, it *is* an auto-generated method that is installed in the namespace. Just like “bar”. So either we should show both, or neither. Or introduce a flag to include/exclude auto-generated methods. But then we would need to mark those methods as auto-generated somehow.
The RT System itself - Status changed from 'new' to 'open'
https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639
I' think we should test that both are listed, and we can close the ticket.
On 2017-10-13 04:50:32, elizabeth wrote:
On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT) \perl6\-bugs\-followup@​perl\.org wrote:
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132283] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=132283 >
Code: class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
¦«2015.12»: (bar)
¦«2016.06»: (bar)
¦«2016.12»: (bar)
¦«2017.06»: (bar)
¦«f72be0f130cf»: (bar BUILDALL)
Bisectable points at two relevant commits: First it was BUILDALL_UNDER_CONSTRUCTION after https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc Now it is BUILDALL after https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
I don't know if BUILDALL should be listed or not. My gut feeling says that it shouldn't be, but feel free to argue otherwise. I'm just the messenger.
Well, it *is* an auto-generated method that is installed in the namespace. Just like “bar”. So either we should show both, or neither. Or introduce a flag to include/exclude auto-generated methods. But then we would need to mark those methods as auto- generated somehow.
On Sat, 21 Oct 2017 08:18:46 -0700, alex.jakimenko@gmail.com wrote:
https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639
I' think we should test that both are listed, and we can close the ticket.
I don't think we should force all future implementations to add BUILDALL. Especially since Rakudo didn't need this added to work correctly.
On 2017-10-13 04:50:32, elizabeth wrote:
On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT) \perl6\-bugs\-followup@​perl\.org wrote:
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132283] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=132283 >
Code: class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
¦«2015.12»: (bar)
¦«2016.06»: (bar)
¦«2016.12»: (bar)
¦«2017.06»: (bar)
¦«f72be0f130cf»: (bar BUILDALL)
Bisectable points at two relevant commits: First it was BUILDALL_UNDER_CONSTRUCTION after
https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc Now it is BUILDALL after
https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
I don't know if BUILDALL should be listed or not. My gut feeling says that it shouldn't be, but feel free to argue otherwise. I'm just the messenger.
Well, it *is* an auto-generated method that is installed in the namespace. Just like “bar”. So either we should show both, or neither. Or introduce a flag to include/exclude auto-generated methods. But then we would need to mark those methods as auto- generated somehow.
I think BUILDALL is different than bar for several reasons, it is all uppercase (which usually means it is special) it is only an optimization the programmer didn't use a pragma to add it the programmer didn't even implicitly declare it
(I mean that 「has $.bar」 as an implicit declaration of a method of the same name)
So I think discussing whether this use of BUILDALL needs to be hidden can be discussed independently of whether an atribute method needs to be hidden.
“I don't think we should force all future implementations to add BUILDALL.”
Not sure what this remark is for. Can be rakudo tests.
On 2017-10-21 09:12:32, brad wrote:
On Sat, 21 Oct 2017 08:18:46 -0700, alex.jakimenko@gmail.com wrote:
https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639
I' think we should test that both are listed, and we can close the ticket.
I don't think we should force all future implementations to add BUILDALL. Especially since Rakudo didn't need this added to work correctly.
On 2017-10-13 04:50:32, elizabeth wrote:
On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT) \perl6\-bugs\-followup@​perl\.org wrote:
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132283] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=132283 >
Code: class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
¦«2015.12»: (bar)
¦«2016.06»: (bar)
¦«2016.12»: (bar)
¦«2017.06»: (bar)
¦«f72be0f130cf»: (bar BUILDALL)
Bisectable points at two relevant commits: First it was BUILDALL_UNDER_CONSTRUCTION after
https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc Now it is BUILDALL after
https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
I don't know if BUILDALL should be listed or not. My gut feeling says that it shouldn't be, but feel free to argue otherwise. I'm just the messenger.
Well, it *is* an auto-generated method that is installed in the namespace. Just like “bar”. So either we should show both, or neither. Or introduce a flag to include/exclude auto-generated methods. But then we would need to mark those methods as auto- generated somehow.
I think BUILDALL is different than bar for several reasons, it is all uppercase (which usually means it is special) it is only an optimization the programmer didn't use a pragma to add it the programmer didn't even implicitly declare it
(I mean that 「has $.bar」 as an implicit declaration of a method of the same name)
So I think discussing whether this use of BUILDALL needs to be hidden can be discussed independently of whether an atribute method needs to be hidden.
On Sat, Oct 21, 2017 at 12:12 PM, Brad Gilbert via RT \< perl6-bugs-followup@perl.org> wrote:
On Sat, 21 Oct 2017 08:18:46 -0700, alex.jakimenko@gmail.com wrote:
https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639
I' think we should test that both are listed, and we can close the ticket.
I don't think we should force all future implementations to add BUILDALL.
Being listed in the methods does not mean part of the spec. I mean, if it did then .^methods wouldn't be allowed to show user added methods either. Or did you mean something else here? in which case you need to explain it better.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
You're right, sorry, I should've been more clear.
Tickets are not closed without tests, but as you pointed out not everything should be spec-ed. That's correct. Therefore, some tests go to https://github.com/rakudo/rakudo/tree/nom/t (these tests can be changed at any moment and don't serve as a guarantee for anything, they exist merely to keep rakudo from regressing). I don't know if there are docs on that topic anywhere. I mentioned it in the squashathon guide (https://github.com/rakudo/rakudo/wiki/Rakudo-SQUASHathon-Guide#resolving-testneeded-tickets) but we probably need a proper explanation somewhere.
On 2017-10-21 11:54:34, allbery.b@gmail.com wrote:
On Sat, Oct 21, 2017 at 12:12 PM, Brad Gilbert via RT \< perl6-bugs-followup@perl.org> wrote:
On Sat, 21 Oct 2017 08:18:46 -0700, alex.jakimenko@gmail.com wrote:
https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639
I' think we should test that both are listed, and we can close the ticket.
I don't think we should force all future implementations to add BUILDALL.
Being listed in the methods does not mean part of the spec. I mean, if it did then .^methods wouldn't be allowed to show user added methods either. Or did you mean something else here? in which case you need to explain it better.
@zoffixznet - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#132283 (status was 'resolved')
Searchable as RT132283$