Lexical filehandles: unblessed but (sometimes) can

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
[download]

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
[download]

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
[download]

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
}
[download]

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
[download]

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
[download]

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)
[download]

So, of course I did

my $fh = IO::File-> new( 'some.log', 'w' );
[download]

and everything works. But, all of the above leaves impression of unclear purposes and behaviour, and possible troubles ahead, for unwary :).

Comment on Lexical filehandles: unblessed but (sometimes) can Select or Download Code

Replies are listed 'Best First'.
Re: Lexical filehandles: unblessed but (sometimes) can by choroba (Cardinal) on Mar 15, 2018 at 13:55 UTC
I fear the answer is simple: legacy, backward compatibility, historical reasons. Printing to filehandles existed before objects in Perl. ($q=q:Sq=~/;[c](.)(.)/;chr(-\|\|-\|5+lengthSq)`"S\|oS2"`map{chr \|+ord }map{substrSq`S_+\|`\|}3E\|-\|`7**2-3:)=~y+S\|`+$1,++print+eval$q,q,a, [download]	[reply] [d/l]
Re: Lexical filehandles: unblessed but (sometimes) can by ikegami (Patriarch) on Mar 15, 2018 at 19:44 UTC
`$fh` contains a reference to a glob. The glob isn't blessed. However, the IO object referenced by the glob is blessed. `$ perl -MScalar::Util=blessed,reftype -E' open my $fh, ">", \my $buf; say reftype($fh) // "[not a ref]"; say blessed($fh) // "[not blessed]"; say reftype($fh{IO}) // "[not a ref]"; say blessed($fh{IO}) // "[not blessed]"; ' GLOB [not blessed] IO IO::File` [download]	[reply] [d/l] [select]
Re^2: Lexical filehandles: unblessed but (sometimes) can by vr (Curate) on Mar 15, 2018 at 21:02 UTC
`use strict; use warnings; use feature qw/ say /; use Scalar::Util qw/ blessed/; open my $fh, ">", undef; say blessed( $fh{ IO }); # IO::File say $fh{ IO }-> can( "print" ) ? "yes" : "no"; # no autoflush $fh 1; say $fh{ IO }-> can( "print" ) ? "yes" : "no"; # yes` [download] And: `use strict; use warnings; use Log::Log4perl qw / :easy /; use Log::Dispatch::Handle; open my $fh, ">", undef; #autoflush $fh 1; my $app = Log::Log4perl::Appender-> new( "Log::Dispatch::Handle", handle => $fh{ IO }); __END__ The IO::File class is missing the 'print' method` [download] And uncommenting the comment makes the program run OK and error message gone.	[reply] [d/l] [select]
Re^3: Lexical filehandles: unblessed but (sometimes) can by ikegami (Patriarch) on Mar 16, 2018 at 20:18 UTC
That's because IO::File is loaded on demand. (One used to have to load it explicitly.) You can change the output to yes-yes by explicitly loading it.	[reply]
Re^4: Lexical filehandles: unblessed but (sometimes) can by vr (Curate) on Mar 17, 2018 at 13:45 UTC


good chemistry is complicated, and a little bit messy -LW
	PerlMonks