Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^3: On Backwards Compatibility and Bareword Filehandles

by chromatic (Archbishop)
on Jul 18, 2020 at 18:08 UTC ( #11119501=note: print w/replies, xml ) Need Help??


in reply to Re^2: On Backwards Compatibility and Bareword Filehandles
in thread On Backwards Compatibility and Bareword Filehandles

Another problem is philosophical: removing features from the language because you do not like that style is not the Perl way.

I continue to fail to understand this argument. Who is saying "bareword filehandles should go away solely because I don't like the style"

Can you do Chesterton's Fence here? What technical arguments are there for discouraging bareword filehandles? Or, to make this easier, undeclared barewords in general?

  • Comment on Re^3: On Backwards Compatibility and Bareword Filehandles

Replies are listed 'Best First'.
Re^4: On Backwards Compatibility and Bareword Filehandles
by ikegami (Pope) on Jul 19, 2020 at 11:47 UTC

    What technical arguments are there for discouraging bareword filehandles?

    There's the lack of scoping. You could use open(local *FOO, ...) to protect the caller, though. So I guess the real problem is that lack of scope-enforcement under use strict;.

    Also, they're very low on the totem pole, so they can end up meaning something unexpected.

Re^4: On Backwards Compatibility and Bareword Filehandles
by jcb (Vicar) on Jul 19, 2020 at 04:01 UTC

    That is a short summary of the impression that I got from previous discussions on the topic of indirect filehandles in Perl, particularly in the case of code at the top-level of the main script, where a (global) bareword filehandle and a file-scope lexical have effectively the same scope.

    There seems to be some confusion here — I am arguing that bareword filehandles should remain in the language, but suggesting a compromise of making bareword filehandles lexical variables. I expect that the arguments in favor of declaring bareword filehandles (and giving them lexical scope) are essentially the rationale for use strict 'subs' prohibiting the old "bareword-as-unquoted-string" behavior.

      where a (global) bareword filehandle and a file-scope lexical have effectively the same scope.

      Globs (which you call bareword file handle) and other package variables are global, which means visible everywhere.

      File-scoped lexicals are still lexically-scoped. They aren't seen outside the file.

        package variables are global, which means visible everywhere.

        Close — fully-qualified names are visible everywhere, but most "global" variables are implicitly scoped to the current package.

        File-scoped lexicals are still lexically-scoped. They aren't seen outside the file.

        If a 1:1 correspondence between files and packages (as is convention) is maintained, those are equivalent, with the exception that you can refer to a package "global" variable from elsewhere if you specifically do so. In terms of "accidents", the risks for a package variable and file-scope lexical are very similar.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11119501]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2020-09-25 10:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    If at first I donít succeed, I Ö










    Results (137 votes). Check out past polls.

    Notices?