develooper Front page | perl.perl5.porters | Postings from February 2013

Re: Don't patch perlopentut: rewrite it completely

Thread Previous | Thread Next
Christian Millour
February 17, 2013 18:55
Re: Don't patch perlopentut: rewrite it completely
Message ID:
Le 17/02/2013 18:33, Ricardo Signes a écrit :
> * Tom Christiansen <> [2013-02-17T12:06:33]
>> What you want to call lexical filehandles is missing the essential point
>> of autovivification of anonymous handles, which has nothing to do with scope.
> The other reason to say lexical filehandle is that it is a much shorter piece
> of jargon than "lexically scoped name for an autovivified indirect filehandle."
> If I tell someone, "Your code uses global names for filehandles, please use
> lexical ones," I mean to use the above mentioned LSNFAIFs.  The example you
> gave of a lexically named non-autovivified handle was:
>>      my $fh = \*STDOUT;
>>      print $fh "Now you see it.\n";
> ...which, is a good example of your point, but sidesteps the issue that what
> people mean by "lexical filehandle" is one that is *both* autovivified *and*
> has (only) a lexically scoped name.
> So, if the standard practice is to use that type of handle unless there is a
> reason to do otherwise, I think having some short signifier for them is good.
> So far, it has been "lexical filehandle," which doesn't bother me too much,
> because not only the name but also the filehandle's life, is tied to the
> lexical scope.

hmmm, no. It is common to open a file for reading using a "lexically 
named filehandle" in some init sub, and then pass it to some kind of 
parser, in which case the filehandle is definitely expected to survive 
its creation block.

[ FWIW, and with the benefit of hindsight, this is one of the reasons I 
do not spell the close on read-only filehandles. With the scenario 
above, I will expect the filehandle to be automatically closed when it 
is not needed anymore, possibly when the parser itself is destroyed, or 
maybe in some other finalization or cleanup sub, neither of which has to 
be lexically triggered. Any read errors will be caught and handled by 
the parser itself. The only reason for closing the filehandle is to free 
the resources it uses (file descriptors and such) so you need to close 
it as soon as possible but IMO you do not need to babysit the closing 
process, and I am content with autoclosing when the refcount drops to 0. ]

  "lexical filehandle," here, in contrast to the idea of a
> mere lexical name for a filehandle.  (Of course lexicality is entirely about
> names, but here we point out that the name dictates the duration of the thing
> under discussion.)
> I cede that the term is indistinct, and I think the message that I've so
> lightly quoted did an excellent job of demonstrating the two relevant
> characteristics, but I think that we may be at a point now where the jargon is
> a bit confusing, but is also in wide use.  It may be better to point out the
> conceptual blurring in a footnote than to attempt to introduce a yet-unadopted
> piece of jargon.  (Or, worse, to tell people to use every required adjective
> every time.)
> In other words, to repeat myself, if this specific set of behaviors is the one
> to be used by default, it needs a simple moniker.

anonymous filehandles ? (by contrast to \*STDOUT, \*STDIN, etc) ?

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About