Another possibility is to override local *CORE::GLOBAL::readline.
I'm not sure that the tied handle interface is the way to manage specialized data handling at the user's end. It seems more suited to hooking up a very different data structure to an I/O-centric application. Something like fetching DBI statement handle results as if they were lines from a CSV file.
It's no secret that I've slowly become a believer in tie. As I said somewhere else, tied interfaces are slower because they are doing something. Presumably, it should be something worth doing - something that would otherwise have to be done explicitly, in multiple places.
As a matter of taste, I'm not sure that should encompass new conventions which modify standard perl semantics. We're accustomed to the diamond op returning a single $/-delimited line in scalar context, and the list of all lines in array context. To produce a tied handle interface that alters those semantics seems backwards to me.
In Tie::Constrained, I found that tie provided a wedge into assignment that is unavailable with any other Perl construct. I notice that there is a similar opportunity in tied handles. A "file" handle can be produced which fails with a preset system error, on a particular kind of operation. That could be valuable for testing. Imagine being able to test for correct error handling when an operation on STDERR returns EPERM or ENOSPC.
It's a well-known wart on Perl that global print is not overridable (that's why Fatal doesn't work for print). With a tied interface, we have the PRINT method. That is another unique wedge into an otherwise immutable bit of Perl.
Whether I like this particular tied handle class or not, this is a very interesting topic. I'm glad you brought it up.
After Compline,
Zaxo
In reply to Re: RFC: Tying Filehandles
by Zaxo
in thread RFC: Tying Filehandles
by Limbic~Region
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |