Fortunately, most of the code does not rely on being able to use in-memory filehandles, only the feature for parsing "application/warc-fields" from a string. Unfortunately, that feature is how the test suite tests parsing
Here's something that works down to at least 5.6, or just use File::Temp in the first place, or IO::String for that matter:
sub tempfh { my $data = shift; my $fh; eval { open $fh, "<", \$data or die $!; 1 } or do { require File::Temp; $fh = File::Temp::tempfile(); print $fh $data; seek $fh, 0, 0 or die "seek: $!"; }; return $fh; }
However, having worked quite heavily with tied filehandles myself, I can say: They're neat, and allow for some cool stuff like my File::Replace::Inplace module, but I strongly recommend against making them a central part of your API unless you have to. There's various issues across various version of Perl - for example, look at the hoops I have to jump through in t/25_tie_handle_argv.t lines 41-49 (and 70-71) just to get the tests working. And even in my module File::Replace, I've come to prefer the API without tied filehandles, even though I initially thought they were pretty neat.
So from my experience let me suggest: use tied filehandles if they're the only way to provide certain APIs (such as my File::Replace::Inplace, or the transparent uncompression of the IO::Uncompress::* family), but otherwise, make your API OO based (modeling it on IO::Handle, if you like), and provide a tied API only as an optional layer of sugar.
Update: Improved wording.
In reply to Re^3: How to declare a dependency on PerlIO in a CPAN module?
by haukex
in thread How to declare a dependency on PerlIO in a CPAN module?
by jcb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |