Re^5: Un "tie"ing a "tie"

Obviously I agree that the implementation is incomplete; and yes, it is orthogonal to the OP's question. A user of a module like this would be responsible for managing their own filehandles -- as earlier answers said: store a dup of STDOUT.

Support for all the special variables needs a little thought, because they are dynamically scoped. I'd probably want to capture their values in the "open" function and store those values in the object. But, OTOH, maybe someone changing the values dynamically knows what they're doing.

I'm not sure that binmode is required for this filehandle. All it does is call a user-defined perl function for each line (implicitly text). If that code prints to a "real" filehandle, then it is that filehandle that needs to support binmode.

I'd be interested to know how to rewrite the "open" function to avoid needing 5.8.x -- the requirement exists because of bugs in 5.6.x, so the simplest (and safest) thing it to require a version of perl that works reliably with tied filehandles.

The conclusion I'd draw from this is that filehandles aren't as simple as we'd like -- because there's more underlying complexity than initially apparent.

--Dave
Opinions my own; statements of fact may be in error.

Comment on Re^5: Un "tie"ing a "tie"

Replies are listed 'Best First'.
Re^6: Un "tie"ing a "tie" by ikegami (Patriarch) on Apr 18, 2006 at 00:57 UTC
I spent time addressing all these concerns in my post. I find it weird that you chose to disreguard them when suggesting an improvement. Support for all the special variables needs a little thought, because they are dynamically scoped. I'd probably want to capture their values in the "open" function and store those values in the object. Actually, it's much simpler than that. Inherit PRINT and PRINTF from Tie::Handle, and override WRITE like I did. I'm not sure that binmode is required for this filehandle. All it does is call a user-defined perl function for each line (implicitly text). If that code prints to a "real" filehandle, then it is that filehandle that needs to support binmode. It should have a dummy in case you want to use the handle somewhere that calls `binmode`. As is, it can't be used as a replacement for a normal file handle, which is the whole reason to use `tie`. I'd be interested to know how to rewrite the "open" function to avoid needing 5.8.x -- the requirement exists because of bugs in 5.6.x, so the simplest (and safest) thing it to require a version of perl that works reliably with tied filehandles. See `wrap` in my post. It works fine in 5.6.1.	[reply] [d/l] [select]
Re^7: Un "tie"ing a "tie" by dpuu (Chaplain) on Apr 18, 2006 at 01:32 UTC
I spent time addressing all these concerns in my post. I find it weird that you chose to disreguard them when suggesting an improvement. Sorry. I cut&paste from one of my existing scripts (which didn't support them), and didn't spend the time to merge it with yours. Yes, I probably should think about modifying my code to take some of the improvements you suggest Your "wrap" works because you are willing to require the user to pass the handle-container in as a typeglob (returning localised filehandles starts to hit the bugs). I didn't want to do that because the natural interface is a signature of (&) so that its single arg is a codeblock. To mimic the "open" builtin it'd need a signature of (*&) which would clutter user-code with the "sub" keyword. --Dave Opinions my own; statements of fact may be in error.	[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks