Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^2: On Backwards Compatibility and Bareword Filehandles

by jcb (Parson)
on Jul 17, 2020 at 23:29 UTC ( [id://11119470]=note: print w/replies, xml ) Need Help??


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

The problem with using scalars for all I/O handles is all of the existing code that uses barewords; this solution maintains backwards compatibility at least for the simple cases that I expect are the most common.

Another problem is philosophical: removing features from the language because you do not like that style is not the Perl way. Perl advocates TIMTOWTDI; One True Right And Only Way is Python's niche and Python fills that niche very well.

Replies are listed 'Best First'.
Re^3: On Backwards Compatibility and Bareword Filehandles
by chromatic (Archbishop) on Jul 18, 2020 at 18:08 UTC
    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?

      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.

      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.

Re^3: On Backwards Compatibility and Bareword Filehandles
by ikegami (Patriarch) on Jul 19, 2020 at 11:56 UTC

    It would be far simpler to automatically convert

    open(FOO, ...)

    to

    open(local *FOO, ...)

    instead. While FOO is still technically global, the caller is protected.

    Note that automatically limiting the scope of variables used as file handles will break code.

      Or if barewords can no longer be used as a file handles, you could pre-declare them using

      use Symbol qw( gensym ); sub FOO { state $fh = gensym(); $fh } open(FOO, ...)

      This is close, but does not actually give the same benefits. Lexical bareword filehandles move a bit of complexity into the parser, but allow the *foo{IO} slot to be removed from GV, simplifying the rest of the interpreter guts. Lexical bareword filehandles allow at least the simple cases to continue to work, even though I/O would be done only through =IO objects.

      Some breakage is to be expected across major versions, but the goal is to maximize the amount of old code that continues to work, while still improving perl and its I/O handling.

        This is close, but does not actually give the same benefits

        You said the problem you're solving is a need to avoid barewords. (You didn't justify that, but fine, I can imagine a reason or two.) What I provided solves the problem. If your solution provides different benefits, does that mean it doesn't solve the stated problem?

        Ok, let's assumes you meant it provides additional benefits. We'll come back to that.

        allow the *foo{IO} slot to be removed from GV

        No, it doesn't. You can't break every XS module that interacts with Perl file handles.

        Lexical bareword filehandles allow at least the simple cases to continue to work

        No it doesn't. It would cause the following to fail:

        sub f { print FH ...; } open FH, '>', ...; f();

        Lexical bareword filehandles move a bit of complexity into the parser

        Except the complexity isn't moved. Your solution adds complexity. Your proposal invents a whole new type system based on heuristics that's nothing like anything in Perl already, when you could simply localize the globs implicitly. This doesn't just add complexity in the parser; it really complicates the language. This affects programmers, not just the people working on perl itself, so this is far worse.

        improving perl and its I/O handling.

        You said the goal was to avoid barewords. You didn't identify any "problem with I/O handling", whatever that means.

        Some breakage is to be expected across major versions, but the goal is to maximize the amount of old code that continues to work, while still improving perl and its I/O handling.

        Everything I said assumed that the goal as worthwhile. None of the my objections have been about the goal, which would necessarily cause breakage; that's a separate discussion. That means converting open(FOO, ...) to open(local *FOO, ...) would cause that same breakage. But it's a far far better solution to the stated goal.

        Earlier, I said I'll presume you meant your solution provides additional benefits over the one I proposed. Well, if that's the case, I'm still waiting to see what they are.


        Update: This was was posted without my knowledge while I was still composing. I ended up with two posts which I've merged.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (9)
As of 2024-03-28 10:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found