Well. I did test. I even installed an ancient perl 5.8.8 to make sure it hasn't been patched somewhere in between. You are right, I am wrong. I bow my head in shame.
But although I was wrong I still recommend to use variables for filehandles because a namespace collision may happen even though one carefully grepped the source code.
There's another issue and I misremembered it. I deliberately do something obviously stupid here to provoke the error.
#!/usr/bin/perl
use strict;
use warnings;
open say, '<', '/etc/nsswitch.conf'
or die "Unable to open file1: $!\n";
print "Filehandle is now open!\n";
print "1: " . <say>;
exit;
This results in:
Filehandle is now open!
1: # /etc/nsswitch.conf
You'll probably also get a warning: 'Unquoted string "say" may clash with future reserved word at <script> line 8.' - something fishy is going on here. In a simple script you're likely to notice it. In a web- or GUI-driven application you probably don't.
Let's upgrade our perl and add a single line
use 5.010;
And suddenly the previously 'well-behaving' application goes boom.
Name "main::say" used only once: possible typo at <script> line 13.
Use of uninitialized value $_ in say at <script> line 8.
Can't use string ("1") as a symbol ref while "strict refs" in use at <
+script> line 8.
What?!!
'use 5.10' exports 'say()' into your namespace. And suddenly open() does not open a filehandle 'say' but a function say(). Boom. Trying to debug that in a real world application may cause some serious headscratching - it's not that obvious anymore - especially if there's nobody warning you that library 'xyz' may accidently export your favourite filehandle name in the future. |