* Tom Christiansen <tchrist@perl.com> [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. "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. -- rjbsThread Previous | Thread Next