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.
| [reply] |
I spend much time training colleagues in Perl.
I'm pretty happy when they understood scoping rules and follow the basics of declaring with my.
And believe me, nobody there thought much about using package before I started there.
There is simply not much room to tell a beginner about all the specialties of a package scoped bareword, which needs to be treated with local, the internals of type-globs and how to pass them around as reference with \*FH .
Yes Perl has many ways to do it and it's impressive how I can always come up with a nifty trick to fix the sins of a 15 year old code base.
But orthogonality rules, they don't need to learn how to use a baseball bat to drive a nail into the wall, if there is a hammer called my $FH and they already learned to use that hammer with many other nails ...
And there is no issue with "backwards compatibility" whatsoever!
| [reply] [d/l] [select] |
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?
| [reply] [d/l] [select] |
| [reply] |