Re^5: Writing a better Modern::Perl

[JavaFan]

or "this code will trigger a bug in 5.YYY, which was fixed in 5.XXX".

There wouldn't be a need for a pragma in that scenario. features is used for backwards incompatible changes, not pure bug fixes.

I may not have expressed myself well enough. What I mean is that sometimes I put a "use 5.006;" (to take an example) on the code, not because it uses a feature that isn't present in 5.005, but because it uses a construct that triggers a bug in 5.00504. (I remember a long debugging session related to regexes, where I was initially unable to reproduce to reported issue - it turned out the regex triggered a bug in one of the latest minor releases of the previous major release).

Now it mean "if you try to run this with 5.YYY, I'm going to keep quiet if you screw up". Not what I expect of a helpful language.

I don't know what you mean. What errors does use 5.xxx; silence?

What I mean is the following:

    use 5.012;
    use warnings;
    ... code ...

Note the absence of 'use strict;', because it's implied by the use 5.012. Someone comes along, who notices the code actually runs fine under 5.10 (its extensive test suite passes). Removal of the 'use 5.012' (or changing it to 'use 5.010') means that the code isn't protected by 'use strict'. Hence, any further modification of the code is subject to the same dangers any code without 'use strict' is.

[chromatic]

Removal of the 'use 5.012' (or changing it to 'use 5.010') means that the code isn't protected by 'use strict'. Hence, any further modification of the code is subject to the same dangers any code without 'use strict' is.

In any project where I have a say in coding standards, all files must declare an expected version of Perl 5. That's the only hope Perl 5 has of getting out of the compatibility morass, and it's good discipline anyway.

(I realize that doesn't help when someone changes use 5.012; to use 5.010;, but it's a start.)

[ikegami]

If your shop's guidelines stated "Support versions of Perl that are older than 5 years old are a time sink.", that would make more sense than simply requiring the version to be stated. You'd see me start putting the following in my files:

BEGIN { die "Unsupported version of Perl\n" if $] >= 5.000000 }

What you suggest is a bad standard as it requires a waste of time to determine the supported version of Perl when that is of no consequence.

[chromatic]

What you suggest is a bad standard as it requires a waste of time to determine the supported version of Perl when that is of no consequence.

I'd like to think a decent Perl 5 programmer has some idea of the version of the language to which he or she programs. If you can only deploy to 5.008, write use 5.008; at the start of all of your programs and no one will be tempted to use defined-or or state or given/when, whereas if you want to use any of those features, you'd better specify the language version.

Let's stop pretending there aren't mildly incompatible versions of Perl 5 The Language. feature has taken away that fiction.

[ikegami]

Of course you won't necessarily get an error. If you would necessarily get an error, there would be no need to add features in the first place. Your expectations don't make only sense. features affects how code behaves. If you stop using it, it will behave differently.

$ perl -e'           sub say(&@) { "..." } say { "..." };'

$ perl -e'use 5.010; sub say(&@) { "..." } say { "..." };'
syntax error at -e line 1, near "};"
Execution of -e aborted due to compilation errors.

$ perl -e'           print $x;'

$ perl -e'use 5.012; print $x;'
Global symbol "$x" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.

$ perl -e'           die "Validation error" if uc(chr(0xE9))=~/\xC9/;'

$ perl -e'use 5.012; die "Validation error" if uc(chr(0xE9))=~/\xC9/;'
Validation error at -e line 1.