If your code works with 5.32, why won't it work with 7?
If you aren’t inclined to change your code, plenty will break if the p7 announcement post is accurate—because flipping strict and turning off bareword file handles and indirect object calls breaks a lot of code. If you are willing to change some pragmas, then nothing will break in 7. But what seems to bother me and almost no-one else is: they explicitly say you will lose compatibility promises when they move to 8–even guessed out loud that indirect object notation could be removed in 8 as an example. And they clearly don’t plan to wait too long to make that jump. What actually transpires may be very different, but I’m taking what was presented at face value, and I personally think it’s unwise. I could be convinced in the face of large gains (I listed a few that I would consider worth some breakage), but breaking compatibility because you think signatures look better where prototypes are? No thanks.
| [reply] |
If your code only works properly without strict, wasn't your code already broken? And broken by design? Unless you're talking about one liners (which will likely be just fine with the automatic compatibility mode on -e), only people who write code that would be a nightmare to review and maintain anyway will be caught off guard by perl7.
| [reply]
[d/l] |
No, that reasoning is wrong.
You may see those "best practices" as an end in itself. I don't. I consider those practices something useful that allows me to write better code, catch more errors, etc. and that's why I use them. But then, if for some reason I get to some place where they get in the way I just ignore them without a blink.
I have modules that don't use strict or warnings; I have code that uses bareword filehandles; probably, I have code that goes against any "best practice" of those that could become forced in perl 7.
And it is good, reliable, beautiful code...
| [reply] |
If your code only works properly without strict, wasn't your code already broken? And broken by design?
that! (*points at you*) is the attitude that disgusted me so much from the announcements. SawyerX, is that you? LOL
Wow. I don't know if it's still true today, but back when Perl was actually popular there were 1,000 "single-screen scripts" out in the wild for every CPAN module or application framework. And, emphatically and forever, I say it's silly to call those broken by design, or bad code, just because they didn't put unnecessary constraints on themselves.
Anonymous, I script everything. Bash, sed, perl, python, lua, pwsh, and tons of others (but never once in awk, true fact). I write scripts that write scripts so I can script while I'm scripting. And I am here to bring you the good news that there is a wide wide spectrum of scripting tasks out there, and one size does not fit all.
So sure, when you get past that one-screen level of script, you start to care more about misspelling a variable, and you don't mind spending a couple lines of code making sure $3 isn't undef before you splice it into a string. Probably 2/3rds of my perl scripts are strict+warnings, and factored into modules, and all that. But, Anonymous Monk, listen to me now and hear me later: the single screen, non-mission-critical, just-lives-in-my-$HOME scripting... the -p scripting where $cnt++ comes out of nowhere but totally has your back when you need the count at the END, is some of the best scripting there is. That's the 20-minutes of scripting that does the next 8 hours of your job while you browse XKCD. Don't miss out on that scripting, Anonymous.
Broken? ...like a fox!
| [reply]
[d/l]
[select] |