BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

p6rt commented 6 years ago

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

Searchable as RT132283$

p6rt commented 6 years ago

From @AlexDaniel

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.

p6rt commented 6 years ago

From @lizmat

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.

p6rt commented 6 years ago

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

p6rt commented 6 years ago

From @AlexDaniel

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.

p6rt commented 6 years ago

From @b2gills

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.

p6rt commented 6 years ago

From @AlexDaniel

“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.

p6rt commented 6 years ago

From @geekosaur

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

p6rt commented 6 years ago

From @AlexDaniel

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.

p6rt commented 6 years ago

From @zoffixznet

Tests: https://github.com/rakudo/rakudo/commit/20d67a3d4d

p6rt commented 6 years ago

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

Raku / old-issue-tracker