Many items of perl interpreter state are exposed as scalar variables.
This allows you to temporarily change its value, perhaps by a `local`
or `dynamically` assignment:
{
local $, = " and ";
print @values;
}
The "currently selected output filehandle" as used by print/printf is
not so exposed; instead requiring the (honestly-bizarrely named)
select() dance:
{
my $oldh = select $newh;
print "Things"; # this goes to $newh;
select $oldh; # restore the old one.
}
This is bad because in the event of an exception, return, goto or
loopex, the previous value is not restored because that second select()
statement is never reached. This can't happen with the `local` or
`dynamically` assignments, because those are reliably restored even in
those events.
I propose the addition of a new perlvar; perhaps named
{
local ${^OUTPUT_HANDLE} = $newh;
print "Things";
}
to embody the same concept as the previous block involving two select()
expressions, but without that unreliability.
Thoughts?
Or maybe this is sufficiently small and uncontentious as to not bother
with writing an RFC and just go ahead and implement it?
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
This allows you to temporarily change its value, perhaps by a `local`
or `dynamically` assignment:
{
local $, = " and ";
print @values;
}
The "currently selected output filehandle" as used by print/printf is
not so exposed; instead requiring the (honestly-bizarrely named)
select() dance:
{
my $oldh = select $newh;
print "Things"; # this goes to $newh;
select $oldh; # restore the old one.
}
This is bad because in the event of an exception, return, goto or
loopex, the previous value is not restored because that second select()
statement is never reached. This can't happen with the `local` or
`dynamically` assignments, because those are reliably restored even in
those events.
I propose the addition of a new perlvar; perhaps named
{
local ${^OUTPUT_HANDLE} = $newh;
print "Things";
}
to embody the same concept as the previous block involving two select()
expressions, but without that unreliability.
Thoughts?
Or maybe this is sufficiently small and uncontentious as to not bother
with writing an RFC and just go ahead and implement it?
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/