search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.93k stars 552 forks source link

Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz #16377

Closed p5pRT closed 6 years ago

p5pRT commented 6 years ago

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

Searchable as RT132760$

p5pRT commented 6 years ago

From darren@DarrenDuncan.net

For the record\, I strongly support the idea that things which don't need to be in a particular sequence to be easily understood should not be required to be in a particular sequence.

Signatures and attributes should be declarable in either sequence\, either one before or after the other. Its really not that difficult for users to understand that either order works.

Even if something is officially experimental\, that doesn't mean there isn't still a high bar for breaking compatibility between Perl versions\, and I don't believe that switching the mandatory order here qualifies.

-- Darren Duncan

p5pRT commented 6 years ago

From @xsawyerx

On 04/21/2018 09​:45 PM\, Darren Duncan wrote​:

For the record\, I strongly support the idea that things which don't need to be in a particular sequence to be easily understood should not be required to be in a particular sequence.

Signatures and attributes should be declarable in either sequence\, either one before or after the other.  Its really not that difficult for users to understand that either order works.

What are you determining this on?

Even if something is officially experimental\, that doesn't mean there isn't still a high bar for breaking compatibility between Perl versions\, and I don't believe that switching the mandatory order here qualifies.

The change was to revert breaking compatibility. I see people keep getting this confused.

Keeping subroutine signatures where they were would break :lvalue subroutine attribute\, which arrived far before subroutine signatures. This *is* about backwards compatibility.

p5pRT commented 6 years ago

From @Leont

On Sun\, Apr 22\, 2018 at 11​:25 AM\, Sawyer X \xsawyerx@​gmail\.com wrote​:

Even if something is officially experimental\, that doesn't mean there isn't still a high bar for breaking compatibility between Perl versions\, and I don't believe that switching the mandatory order here qualifies.

The change was to revert breaking compatibility. I see people keep getting this confused.

Keeping subroutine signatures where they were would break :lvalue subroutine attribute\, which arrived far before subroutine signatures. This *is* about backwards compatibility.

Either I'm not understanding you\, or you are not understanding him. I don't think anyone is arguing against the necessity of change. He's arguing for the other possible solution because it's more compatible with both recent perl versions and with signature implementations on CPAN.

Leon

p5pRT commented 6 years ago

From @iabyn

On Wed\, May 02\, 2018 at 08​:50​:45AM +0200\, Leon Timmermans wrote​:

Either I'm not understanding you\, or you are not understanding him. I don't think anyone is arguing against the necessity of change. He's arguing for the other possible solution because it's more compatible with both recent perl versions and with signature implementations on CPAN.

I'm not aware of "the other possible solution". What is that?

-- "Emacs isn't a bad OS once you get used to it. It just lacks a decent editor."

p5pRT commented 6 years ago

From @xsawyerx

On 05/02/2018 09​:50 AM\, Leon Timmermans wrote​:

On Sun\, Apr 22\, 2018 at 11​:25 AM\, Sawyer X \xsawyerx@​gmail\.com wrote​:

Even if something is officially experimental\, that doesn't mean there isn't still a high bar for breaking compatibility between Perl versions\, and I don't believe that switching the mandatory order here qualifies. The change was to revert breaking compatibility. I see people keep getting this confused.

Keeping subroutine signatures where they were would break :lvalue subroutine attribute\, which arrived far before subroutine signatures. This *is* about backwards compatibility. Either I'm not understanding you\, or you are not understanding him. I don't think anyone is arguing against the necessity of change. He's arguing for the other possible solution because it's more compatible with both recent perl versions and with signature implementations on CPAN.

I did understand this is an argument for the option of changing the signatures to be on both sides. Perhaps I was not clear on my response. My comment was in response to this sentence fragment​:

  Even if something is officially experimental\, that doesn't mean   there isn't still a high bar for breaking compatibility between Perl   versions [...]

which I understood as "Don't break signatures even though they're experimental\," meaning we should avoid breaking compatibility. My comment was to say we *do* care about compatibility\, there is a high bar\, and that this was *the* reason we decided to revert the order\, *because* of compatibility. (Not of signatures but of :lvalue which was available much earlier than signatures\, so it takes precedence.) Darren expressed the need for compatibility and I agreed\, but with something else\, not signatures.

I should have added that we did raise the possibility of putting signatures on both sides. (In fact\, *I* raised it when looking for comments on it.) However\, that did not receive backing and there was expressed disinterest in doing this.

I apologize for the confusion caused by my response.

p5pRT commented 6 years ago

From @eserte

Dana Fri\, 09 Feb 2018 14​:21​:58 -0800\, slaven@​rezic.de reče​:

Dana Wed\, 24 Jan 2018 12​:04​:24 -0800\, slaven@​rezic.de reče​:

This is a bug report for perl from slaven@​rezic.de\, generated with the help of perlbug 1.41 running under perl 5.27.8.

----------------------------------------------------------------- List-Lazy-0.3.0 does not work anymore since v5.27.7-212-g894f226e51. This is the change which swapped signatures and attributes. This change is already documented in perldelta\, but I have just two notes​:

- The error output does not look nice. In this case it begins with

Array found where operator expected at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0- 2/blib/lib/List/Lazy.pm line 43\, near "$$@​)" (Missing operator before @​)?) "my" variable $step masks earlier declaration in same statement at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0- 2/blib/lib/List/Lazy.pm line 44. syntax error at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0- 2/blib/lib/List/Lazy.pm line 36\, near ") :" Global symbol "$generator" requires explicit package name (did you forget to declare "my $generator"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0- 2/blib/lib/List/Lazy.pm line 38. Global symbol "$state" requires explicit package name (did you forget to declare "my $state"?) at /home/eserte/.cpan/build/2018012418/List- Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 39. Global symbol "$min" requires explicit package name (did you forget to declare "my $min"?) at /home/eserte/.cpan/build/2018012418/List-Lazy- 0.3.0-2/blib/lib/List/Lazy.pm line 43. Global symbol "$max" requires explicit package name (did you forget to declare "my $max"?) at /home/eserte/.cpan/build/2018012418/List-Lazy- 0.3.0-2/blib/lib/List/Lazy.pm line 43. Global symbol "$step" requires explicit package name (did you forget to declare "my $step"?) at /home/eserte/.cpan/build/2018012418/List- Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 43. Invalid separator character '{' in attribute list at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0- 2/blib/lib/List/Lazy.pm line 44\, near "$step : sub " Global symbol "$step" requires explicit package name (did you forget to declare "my $step"?) at /home/eserte/.cpan/build/2018012418/List- Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 44. ...

which does not really say anything about the problem. Is it possible to detect this situation and improve diagnostics?

- What does this change means in terms of usability of signatures? Users mixing signatures and prototypes must increase their perl prerequisite from 5.22 to 5.28\, which may mean it could be less likely that signatures are used in the next time. Is this worth for this change?

BTW\, the issue for the CPAN module is https://github.com/yanick/List-Lazy/issues/3

-- Slaven

Also affected​: ALEXBYK/Evo-0.0405.tar.gz (Bisect result found out by Andreas)

This ticket was closed\, but at least this module (and possibly also others mentioned here) was not handled. I created an issue in the module's issue tracker​: https://github.com/alexbyk/perl-evo/issues/6

p5pRT commented 6 years ago

From @iabyn

On Wed\, May 23\, 2018 at 11​:30​:15PM -0700\, slaven@​rezic.de via RT wrote​:

This ticket was closed\, but at least this module (and possibly also others mentioned here) was not handled. I created an issue in the module's issue tracker​: https://github.com/alexbyk/perl-evo/issues/6

All affected distributions mentioned in this ticket now either pass on blead or have the following tickets​:

  Evo-0.0405   https://github.com/alexbyk/perl-evo/issues/6   Moxie-0.07   https://github.com/stevan/p5-Moxie/issues/9

-- I thought I was wrong once\, but I was mistaken.