Re^5: Back to the __future_

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.

Comment on Re^5: Back to the __future__ Select or Download Code

Replies are listed 'Best First'.
Re^6: Back to the __future__ by Corion (Patriarch) on Aug 21, 2011 at 13:09 UTC
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^7: Back to the __future__ by JavaFan (Canon) on Aug 21, 2011 at 13:16 UTC
I still want to benefit from behaviour changes. How's that going to work? Really, how can your program benefit from an unknown behaviour change? Except for an isolated, lucky case, I cannot fathom this to be remotely useful. To me it sounds "the more breakage, the better". Because when you say "behaviour change", what you actually mean is "backwards compatability breakage". Because that's what we are talking about. Say, for instance, starting with 5.18, `use 5.18` will imply that division by default is integer division (like C). What benefit will your `use 5.12` have from getting integer division on some versions of Perl, but not on others?	[reply] [d/l] [select]
Re^8: Back to the __future__ by Corion (Patriarch) on Aug 21, 2011 at 13:48 UTC
Let me give an example. I have an (unreleased, DarkPAN) module, List::Part::SmartMatch, which uses the "Smart"match operator `~~` to do matching on a criterion. I don't want to rename this module to List::Part::SmartMatch::5_010 , because actually that module does not care about what the smartmatch operator does. And it's highly unlikely that any user of this module wants anything else than "their view" of how "Smart"match currently behaves. I presume that maybe with 5.016 or later, the `~~` operator gets fixed, but if I had to specify one fixed version for my modules semantics, it would have to stay forever with the broken smartmatch semantics to no fault of its own. This is one case where it would help to either be able to specify "Infinite" upwards compatibility (at least from the foreseeable future), or a convenient way to specify "I want the smartmatch behaviour that my caller expects". Except that the latter would basically be dynamic runtime dispatch of operators, which would be convenient for my case but horrible overkill in the general case.	[reply] [d/l] [select]


Your skill will accomplish what the force of many cannot
	PerlMonks

Re^5: Back to the __future__

Re^5: Back to the future