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

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

Closed
p6rt opened this issue Oct 13, 2017 · 10 comments
Closed
Labels
regression Issue did not exist previously testneeded

Comments

@p6rt
Copy link

p6rt commented Oct 13, 2017

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

Searchable as RT132283$

@p6rt
Copy link
Author

p6rt commented Oct 13, 2017

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 rakudo/rakudo@9837687
Now it is BUILDALL after rakudo/rakudo@63cf246

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
Copy link
Author

p6rt commented Oct 13, 2017

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 rakudo/rakudo@9837687
Now it is BUILDALL after rakudo/rakudo@63cf246

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
Copy link
Author

p6rt commented Oct 13, 2017

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

@p6rt
Copy link
Author

p6rt commented Oct 21, 2017

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
rakudo/rakudo@9837687
Now it is BUILDALL after
rakudo/rakudo@63cf246

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
Copy link
Author

p6rt commented Oct 21, 2017

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

rakudo/rakudo@9837687

Now it is BUILDALL after

rakudo/rakudo@63cf246

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
Copy link
Author

p6rt commented Oct 21, 2017

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

rakudo/rakudo@9837687

Now it is BUILDALL after

rakudo/rakudo@63cf246

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
Copy link
Author

p6rt commented Oct 21, 2017

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
Copy link
Author

p6rt commented Oct 21, 2017

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
Copy link
Author

p6rt commented Dec 11, 2017

From @zoffixznet

Tests​: rakudo/rakudo@20d67a3d4d

@p6rt
Copy link
Author

p6rt commented Dec 11, 2017

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

@p6rt p6rt closed this as completed Dec 11, 2017
@p6rt p6rt added regression Issue did not exist previously testneeded labels Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression Issue did not exist previously testneeded
Projects
None yet
Development

No branches or pull requests

1 participant