in reply to Re^2: Back to the __future__
in thread Back to the __future__

First of all, the least version for which this will apply is 5.16. And that's assuming it can be build before that.

But really, what's is the purpose of saying "I need Perl 5.xx or higher"? The entire point of this exercise is to be able to remove features without breaking. The fact that use 5.006; means "I want lexical filehandles" means we have to support lexical filehandles forever, in the same as it's now.

Say, in 5.20 we have a really awesome feature. You get it with use 5.20;. But a year and a half later, it turns out the feature wasn't so awesome, or it can be made better, but only in a way to break backwards compatibility, Jesse's proposal makes it possible. use 5.20; and use 5.22; will give you the awesome feature, use 5.24; won't, or with a changed syntax and/or semantics.

But if people can say "use 5.20 or something newer", it's not going to work. Then we're back to the same backwards compatibility issues we have right now.

Note that Jesse's proposal doesn't imply that use 5.20; means it's going to croak on 5.22 or 5.24. Not at all. It means that 5.22 or 5.24 is going to emulate the 5.20 behaviour.

Replies are listed 'Best First'.
Re^4: Back to the __future__
by Corion (Patriarch) on Aug 19, 2011 at 12:37 UTC

    I'm of two minds here - on one hand, I understand that I can only guarantee that the code will behave as I wrote it. On the other hand, I trust Perl more than I trust myself in understanding the features, so I want to state what I know about the code, in the sense of minimum requirements, but otherwise tell Perl "Do whatever you think is correct".

    Of course, there will come a point in time when Perl deviates from its behaviour, but I see that as my problem and not as Perls problem. Maybe use v.infinity; would be the proper way to state that I think that the upper bound of Perl version is unknown.

[reply]
[d/l]
      On the other hand, I trust Perl more than I trust myself in understanding the features, so I want to state what I know about the code, in the sense of minimum requirements, but otherwise tell Perl "Do whatever you think is correct".
      I fail to see the benefit of that.

      Suppose we had this scheme already in place, say since 5.8. You specify for a program "oh, give me 5.10 or anything newer, including its changes in behaviour". You did not include use strict;, because your program is doing some tricks that requires it to be off.

      Then 5.12 came along, which defaults to enabling strict. Your program now fails to run. Would that have made you happy?

      Of course, there will come a point in time when Perl deviates from its behaviour, but I see that as my problem and not as Perls problem.
      But it is Perls problem. Backwards compatability has an enormous value. It lowers the bar to write products in Perl. It lowers the bar to upgrade your Perl. Without backwards compatability, Perl would not even have been half so successful as it is now.

      But backwards compatability is also holding us back. We keep having to support old features, and new syntax sometimes is convoluted because a more natural way of writing clashes with some obscure, mostly forgotten, syntax. Remember how long it took before // was accepted? The reason it took so long was because it could clash with existing syntax. We would have had // much earlier if we'd had something like Jesses proposal.

[reply]
[d/l]
[select]

        I understand the benefits of backward compatibility, but I want a way to specify that I (as the module author) don't care if this module breaks some day in the future. I really want to avoid the "check per Perl release" hassle that Mozilla inflicted on Firefox extension authors. They need to re-validate their add-ons with every Firefox release. I don't want to adjust the upper bound of my module compatibility with every new Perl release, but I still want to benefit from behaviour changes. Once Perl makes my module (tests) break, I can then add the upper bound of compatibility.

        I guess the problem could be solved by declaring "infinity" as the upper module bound. Then Perl (testers) would know to ignore the module if a change breaks it, as I'm the one who needs to release a fresh version with the proper compatibility limits.

        Another approach could be to not require versions but features, something that, in theory, the Javascript authors should be doing some years now. But I guess that somehow, use feature went wrong along the way, although I don't remember how and why, except that it is neither part of the discussion nor part of my usage patterns.

[reply]
[d/l]
Re^4: Back to the __future__
by cdarke (Prior) on Aug 19, 2011 at 13:07 UTC
    what's is the purpose of saying "I need Perl 5.xx or higher"?

    That way we can specify a minimum release.

    I suggested that particular syntax because it uses existing syntax rather than inventing new, so versions up to and including 5.14 don't barf.

    I appreciate that the meaning of the use will change to mean emulate a particular release, I'm querying whether that will be always feasible. If a feature needs to be changed, then being able to support both new and old could make the code even more complex, and might not always be possible every time. I think Jesse said as much in his talk, at least that was the impression I got.
[reply]
      That way we can specify a minimum release.
      But why? Keeping the ability to say "I want version X or anything newer" means that there's absolutely no benefit in going with Jesse's proposal. And then we may as well keep what we have. The entire point of the exercise is the ability to change/refine the meaning of existing syntax without breaking existing code.

      Putting the "old" meaning of use back in using a different construct means we're back to square one.

[reply]
[d/l]

In Section Meditations