in reply to Re^7: On Backwards Compatibility and Bareword Filehandles (Orthogonality)
in thread On Backwards Compatibility and Bareword Filehandles
To be clear, I am content with the status quo, but it seems that there is an effort afoot to remove bareword filehandles entirely, and I present this proposal as an alternative change that will cause less breakage than the previously proposed change of removing the feature entirely. I do not think that I can get indefinite continuation of the status quo, so I make this proposal as a "next best thing" from my perspective.
You raise a good point that existing code expects to be able to pass a reference to a bareword filehandle with \*FH. The parser could still accept that syntax and consider it another form of {I/O}FH, but the \* would no longer be required. This would allow passing filehandles as arguments to I/O builtins and user subroutines equivalently.
I am not saying that my $FH should stop working, only that "plain" filehandles should become equivalent to that in preference to being removed entirely. I also see some opportunities to simplify the interpreter guts along the way, which is a suitable justification for change, especially when efforts are made to maximize compatibility with existing code that does not use my $FH, as this proposal seeks. Since you mentioned that even package was not being considered at your workplace before you started, how likely are there to be other places where my $FH is still entirely unknown? How much code will they have?
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^9: On Backwards Compatibility and Bareword Filehandles
by LanX (Saint) on Jul 20, 2020 at 02:29 UTC | |
by ikegami (Patriarch) on Jul 21, 2020 at 18:26 UTC |