vr has asked for the wisdom of the Perl Monks concerning the following question:
(s/lexical filehandles/references to autovivified anonymous filehandles/ig;)
There are some (minor) annoying inconsistencies:
use strict; use warnings; use feature qw/ say /; use Scalar::Util qw/ blessed /; open my $fh, "+>", undef; say $fh-> can( "print" ) ? "yes" : "no"; # no print $fh 123; say $fh-> can( "print" ) ? "yes" : "no"; # no $fh-> print( 123 ); say $fh-> can( "print" ) ? "yes" : "no"; # yes say "no" unless blessed $fh; # no
In case of "print", indirect & direct method invocations obviously compile differently (+ see below), with different side effects, but:
use strict; use warnings; use feature qw/ say /; open my $fh, "+>", undef; say $fh-> can( "print" ) ? "yes" : "no"; # no autoflush $fh 1; say $fh-> can( "print" ) ? "yes" : "no"; # yes
And:
$ perl -MO=Deparse -e ' > open my $fh, "+>", undef; > autoflush $fh 1; > $fh-> autoflush( 1 ); > print $fh 123; > $fh-> print( 123 ); > ' open my $fh, '+>', undef; $fh->autoflush(1); $fh->autoflush(1); print $fh 123; $fh->print(123); -e syntax OK
It's unclear why lexical filehandle can not do its methods from the start, and for what it was made able "to can" after some magic passes. Why bother with waiting to attach this black magic until later (or at all), and not bless poor things to e.g. IO::Handle class, so that they officially can? Performance/resources issue?
But, it looks like e.g. autoflushing on one lexical filehandle results to (costly?) black magic turned on all over the program, in different scopes and packages. If so, it somehow reminds of penalties of using $`, $&, $' in previous days.
use strict; use warnings; use feature qw/ say /; { open my $fh, "+>", undef; say $fh-> can( "print" ) ? "yes" : "no"; # no autoflush $fh 1; say $fh-> can( "print" ) ? "yes" : "no"; # yes } package different; { open my $foo, "+>", undef; open my $bar, "+>", undef; say $foo-> can( "print" ) ? "yes" : "no"; # yes say $bar-> can( "print" ) ? "yes" : "no"; # yes }
Why do I care? :) Just curious, and also yesterday I was playing with Log::Dispatch::Handle:
Basically, anything that implements a print() method can be passed the object constructor and it should work.
So I tried first:
use strict; use warnings; use Log::Log4perl qw / :easy /; use Log::Dispatch::Handle; open my $fh, "+>", undef; my $app = Log::Log4perl::Appender-> new( "Log::Dispatch::Handle", min_level => "debug", newline => 0, handle => $fh ); __END__ GLOB(0x1ea3a0) is missing the 'print' method
Using my "secret weapon" autoflush $fh 1; after open:
Use of uninitialized value $list in concatenation (.) or string at C:/ +berrybrew/5.26.0_64_PDL/perl/vendor/lib/Specio/Constraint/Role/CanTyp +e.pm line 58. GLOB(0x2d6a3a0) is missing the methods
How very bizarre. I must admit, with more recent Perl and Log::*** and dependencies installed, the error message makes more sense:
An unblessed reference (GLOB(0x560dc7cc1348)) will never pass an AnyCa +n check (wants print)
So, of course I did
my $fh = IO::File-> new( 'some.log', 'w' );
and everything works. But, all of the above leaves impression of unclear purposes and behaviour, and possible troubles ahead, for unwary :).
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Lexical filehandles: unblessed but (sometimes) can
by choroba (Cardinal) on Mar 15, 2018 at 13:55 UTC | |
|
Re: Lexical filehandles: unblessed but (sometimes) can
by ikegami (Patriarch) on Mar 15, 2018 at 19:44 UTC | |
by vr (Curate) on Mar 15, 2018 at 21:02 UTC | |
by ikegami (Patriarch) on Mar 16, 2018 at 20:18 UTC | |
by vr (Curate) on Mar 17, 2018 at 13:45 UTC |