Re^2: sub STDERR { *STDERR } -- nearly works !

Using $FH also allows the filehandle to be passed around, assigned, stored in other structures and objects, etc... so that it's a first class thing, not a bag on the back.

I have a collection of "useful widgets" in a module which I use in all my modules and programs. What that currently does is export $STDERR (etc), which is set $STDERR = *main::STDERR{IO}. So my $STDERR is almost as global as STDERR.

This brings the STDxxx filehandles into line with all other filehandles in my code, sharing all the benefits of being first class variables.

If the sub STDERR {*STDERR} worked, then it would be implicitly global and no export of a variable would be required. /sigh/

Comment on Re^2: sub STDERR { *STDERR } -- nearly works ! Select or Download Code

Replies are listed 'Best First'.
Re^3: sub STDERR { *STDERR } -- nearly works ! by ikegami (Patriarch) on Apr 09, 2008 at 09:06 UTC
`*STDERR` is already a perfectly fine first class variable. No need to duplicate it as `$STDERR`. It's especially curious that you point out that a `STDERR` function would be even better in the last paragraph, contradicting the rest of your post (which argues for conformity with other file handles).	[reply] [d/l] [select]
Re^4: sub STDERR { *STDERR } -- nearly works ! by gone2015 (Deacon) on Apr 09, 2008 at 10:07 UTC
Up to a point... `print *FH ....` causes Perl to throw up, where `print $FH ....` doesn't. It appears that a `$STDERR` is more general. Well, yes, I put my hand up on the inconsistency. But, declaring `$STDERR` and exporting it to everywhere it's used is a bit ugly. ...but brother ysth points out the error in my thinking, `$STDERR` does need to be exported after all. So I don't need the `sub` trick after all.	[reply] [d/l] [select]