On Fri, Dec 26, 2008 at 5:12 PM, Roderich Schupp
<roderich.sch...@googlemail.com> wrote:
> Actually, i18n.pm seems to be real culprit: If I switch the order of the
> above "use"s, hello2 runs fine. Same if I replace Term::ReadKey
> with another module that has a shared glue library (and isn't one of the
> core modules already loaded, e.g. Devel::Peek).
Digging a little deeper... Try the following:
$ cat foo.pl
use Archive::Zip qw( :ERROR_CODES );
use i18n;
my $zip = Archive::Zip->new("foo.zip")
or die "error reading foo.zip";
$ perl foo.pl
Can't locate object method "opened" via package "i18n" at
/usr/share/perl5/Archive/Zip/Archive.pm line 431, <STDIN> line 1.
Note that this has nothing to do with PAR (except that PAR uses
Archive::Zip, too). The real culprit is indeed module i18n.
It overloads the perl operator that "constructs" literal strings, e.g.
$ perl -Mi18n -e 'my $str = "some literal text"; print "ref = ", ref
$str, "\n";'
ref = i18n
i.e. $str isn't a plain scalar anymore, but an object of class "i18n".
Now Archive::Zip has a function (_newFileHandle) that returns
a filehandle based on "type" of its only parameter: if it's a string,
interpret it as a file name, open() it and return the filehandle;
but if the parameter is already a reference (think typeglob or IO::Handle),
return just the parameter. OK, "foo.zip" from the first example
is now an "i18n" object courtesy of i18n, gets passed down
from Archive::Zip::new to _newFileHandle, gets returned as is,
but is supposed to be an IO::Handle that "can" opened().
So back to Alan original problem: sorry, no candy -
you just can have both of i18n and Archive::Zip (and PAR
needs Archive::Zip, so it's off, too).
Cheers, Roderich
