Or are you saying that I can get most of the benefits of tied handles by following the IO::Handle interface in the "tied handle" class?
I think it depends. Proving a filehandle interface makes sense if these handles will be passed into other APIs that can take only filehandles. OTOH, if all you want to provide your users is a typical open/while(<>) interface, then IMHO it's easier to provide an OO interface instead of something that looks like a filehandle but really isn't, because next thing you know they might try to do things that are actually not supported. Note that in some cases, other APIs don't even require filehandles, they just need objects that support a subset of their methods (like read), so basically duck typing - Perl sometimes has an extremely flexible notion of what a filehandle is, see e.g. Best way to check if something is a file handle?. So I guess what's "best" depends on what API you want to provide to others?
Most of your hoops to jump through seem to be related to the <> and *ARGV magic rather than to ordinary tied filehandles passed around as references.
Yes, you're right, I thought I remembered more issues with tied handles themselves, but I don't see them at the moment, sorry!
Is your code already online somewhere (GitHub?), for context?
In reply to Re^5: 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: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |