Yes, I'd actually thought DATA might be the problem but I'd tried playing with it in a different way (loading it in
package main before declaring package Xmas, hence it being left a global). Using a pre-populated array like
@days = split/(?=\n)/, <<EODATA;
On the %s day of Christmas, my true love gave to me
A partridge in a pear tree.
Two turtle doves
Three French hens
Four calling birds
Five golden rings.
Six geese a-laying,
Seven swans a-swimming
Eight maids a-milking
Nine ladies dancing
Ten lords a-leaping
Eleven pipers piping
Twelve drummers drumming
EODATA
works, as does reading with <main::DATA>. Freaky. Thanks! | [reply] [d/l] [select] |
(This post is substantially the same as what I said in the Chatterbox. I'm posting it here for future reference.)
[...] works, as does reading with <main::DATA>. Freaky.
Every module can have a __DATA__ section, so the file handle DATA is tied to a package.
But that's not special. While there are a few special file handles which are trully global (STDIN, STDOUT, STDERR and ARGV), all others are stored in lexical variables or package variables. For example,
package AA;
open(FILE, '<', $ARGV[0]) or die("open: $!\n");
package BB;
print(defined(read(FILE, $buf='', 0))?1:0, "\n"); # 0
package AA;
print(defined(read(FILE, $buf='', 0))?1:0, "\n"); # 1
| [reply] [d/l] [select] |
You could try putting "package Xmas;" on the line before __DATA__ - seems to work for changing which package the DATA filehandle appears in.
Of course, the other admonition is to not have multiple packages in a single file - it confuses us mere mortals when convention is broken like that. ;-)
| [reply] |
I dunno about *convention* (lots of modules do it, and very convenient for protoyping/writing demonstration code) but is
against TheDamian's best practices.
--
In Bob We Trust, All Others Bring Data.
| [reply] |