This deprecation affects things like $\cT, where \cT is a literal control
(such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code.
Surprisingly, it appears that originally this was intended as the
canonical way of accessing variables like $^T, with the caret form only being
added as an alternative.
I love perl and use it nigh-unto daily, but—what could possibly have been the thought process behind that? A literal control character?
If you try to use and output ^O while thinking you're outputting a literal control-O then you'll be in for a big surprise.
The language allows (length) 250 or so character variable names with few restrictions, so using single character names is probably a bug or at least bad style, so when the devs are looking for a class of global "internal-ish" variable names, how about those icky single character names that no one should be using? So that's how you end up with $^V being aliased to a string representation of the version of perl interpreter currently executing. You really shouldn't be using single character variable names so they've been repurposed and attempting to re-re-purpose them might be very exciting.
Yes. Its a running joke WRT general global variables, and they all have a single character synonym. And once you use up the preferred letters, well, stranger things are used.
a C programmer who understands command line argument lists would not even remotely be surprised at the contents of the general variable $0. Its probably more "civilized" to call it $PROGRAM_NAME in your code, but whatever. I don't think this is controversial to alias $PROGRAM_NAME to $0 for anyone civilized aka some minimal C experience.
Perl tends to be consistent. In a similar style, if you insist on implementing a global general variable like $PERL_VERSION which contains a string of pretty much what it sounds like it contains, to keep things consistent all general vars also have a single character synonym, so welcome to $"control-V"
In the "real world" you can write something stupid enough to get yourself fired. This kind of activity probably qualifies unless you have an excellent excuse. Perhaps if you have a complicated if-then statement with numerous clauses and using one individual weird, yet short, variable name allows a debugging programmer to keep the whole control flow in their head instead of scrolling the mess off the screen, then, maybe, its a win. But I wouldn't make a habit of it.
Given that you can pretty much transparently "upgrade" or "downgrade" the code with a simple search and replace its not a major crisis.
A lot of people use Perl::Critic as a Perl "lint" and a lot of those users put large amounts of the perlvars file in the Variables::ProhibitEvilVariables test although the Perl::Critic authors don't by default include them, which many people consider a bug in Perl::Critic but whatever.
> Its probably more "civilized" to call it $PROGRAM_NAME in your code, but whatever. I don't think this is controversial to alias $PROGRAM_NAME to $0 for anyone civilized aka some minimal C experience.
$0 (along with $1 etc.) is used in shells, at least bash [and original sh?]. I think Perl just borrowed those, like $ prefixes to variables or not offering explicit subroutine arguments, from the traditional unix shell(s).
Linking yegge is quite pointless, since even in that little screed he demonstrates amply how he doesn't even know the basics of Perl and in fact knows so little that his judgement isn't worth the bytes that store it.
From traditional UNIX shells, by way of awk. perl was originally written as a fancier version of awk (to the point that, until recently, it came with a utility "a2p" that translated awk source code to perl), so that's where it got the variables.
From the perlfunc manpage, about the return values of Perl's operators and functions in scalar versus list context: In general, they do what you want, unless you want consistency.
