It's time to give IO::Scalar the big goodbye. (well, at least after one last bug fix)
The problem is that it doesn't behave like an IO::Handle properly. It's sorta kinda the same, but sufficiently different that you should expect it will break on you eventually.
IO::String on the other hand, is smaller, lighter, doesn't come with 5 other related modules who's tests could fail and block you, and behaves EXACTLY like a filehandle, even down to its seek-past-end-of-file behaviour.
And more importantly, that means it actually works with modules like Archive::Zip that care about seeking. If you currently use IO::Scalar, your module won't work properly with Archive::Zip.
I tried porting over Archive::Builder a couple of days ago as part of my own effort to move all of my CPAN modules over, and in that case it was a simple s/IO::Scalar/IO::String/ and everything Just Worked.
So if your CPAN module uses IO::Scalar currently, consider moving. It may seem a small thing, but it means your module will be able to Play Well With Others much more cleanly.
That is all. :)
That does the same thing as IO::Scalar and IO::String.open my $fh, '>', \my $str;
-Dom
Too many caveats...
Alias on 2006-05-07T11:42:07
That approach is fine if you don't care about anything older than 5.8.0 (which rules out all non-Unicode CPAN modules).
While CPAN is just barely turning the corner and discarding 5.005 and use 5.6 as the new base version, it's nowhere near ready for a 5.8 minimum.
Now for another few years at least.
And worse, you can't validate the damned things either.
DB $str = 'foo';
DB open $fh, '>', \my $str;
DB x $fh
0 GLOB(0x851ca94)
-> *main::$fh
FileHandle({*main::$fh}) => fileno(-1)
DB x $fh->isa('IO::Seekable')
0 ''
So if you goal is to accept params that are seekable handles... well it at least appears that a modern IO::String-alike is not a seekable filehandle.
Of course, if you can answer the question "is seekable" comprehensively and _provably_, there's a lot of beer in it for you:)
