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

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?

Replies are listed 'Best First'.
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]

In Section Meditations