Re^3: On Backwards Compatibility and Bareword Filehandles

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

Existing convention discourages naming subroutines or packages in ALL UPPERCASE anyway, and I do not suggest changing that.

Sure, but I provided two widely-used examples that violate this convention. I could also mention LWP, DBI, CGI....

An explicit "::" can be prefixed to top-level packages when needed or assumed when no parse conflict exists.

The problem is I don't know when a parse conflict will exist.

If I write code with a bareword filehandle in a module, I don't know how that module will be used. I don't know when it will be loaded. I don't know what will be loaded before it and I don't know what will be loaded after it.

If the parser parses this construct in different ways depending on what's loaded, it's fragile and undecidable.

An explicit "::" can be prefixed to top-level packages when needed or assumed when no parse conflict exists.

I don't see how this solves my problem here. I don't want to refer to a top-level package. I want a bareword filehandle (for the sake of argument, at least—I don't want bareword filehandles at all, because of this problem).

Even if this did solve the problem, I don't think it's worth the tradeoff. Now you've introduced another implicit rule, which is that we must prefix all single-word package names to avoid any potential conflict with a bareword filehandle somewhere.

I use a lot more package names than I do filehandles.

Comment on Re^3: On Backwards Compatibility and Bareword Filehandles Select or Download Code

Replies are listed 'Best First'.
Re^4: On Backwards Compatibility and Bareword Filehandles by jcb (Parson) on Jul 19, 2020 at 03:50 UTC
The solution is that lexical bareword filehandles exist only in the scopes where they are declared. Single-word package only need prefixes within the same lexical scope as an identically-named filehandle. The use of a filehandle `YAML` in one block does not affect `YAML` as a package name outside of that block. If I write code with a bareword filehandle in a module, I don't know how that module will be used. I don't know when it will be loaded. I don't know what will be loaded before it and I don't know what will be loaded after it. This proposal is that bareword filehandles in your module would become lexicals, private to your module. If the parser parses this construct in different ways depending on what's loaded, it's fragile and undecidable. This is a misunderstanding. Only lexical declarations affect parsing in this proposal, and `open BAREWORD,...` becomes a lexical declaration. Within the lexical scope of an `open YAML,...`, `YAML` would parse as `{I/O}YAML` and class method calls on `YAML` would need to be written as `::YAML->method(...)` or `method ::YAML (...)`. However, YAML is a bad example here because it has a functional interface, and `YAML::DumpFile(...)` (for example) is already unambiguous, even if `YAML` is a lexical filehandle. Outside of the lexical scope of `open YAML,...`, `YAML` remains a "plain" bareword, and `close YAML` would, for example, parse equivalently to `::YAML->close` — that is, as a class method call on package `YAML`, whether or not `YAML` is actually loaded. Obviously, executing a method call to an undefined class is an error, but parsing in this proposal does not depend on the set of loaded packages, only the lexical declarations in effect. After thinking about this a bit more, is your concern what happens if a module attempts to use a bareword filehandle defined elsewhere? The I/O operations on undeclared filehandle `BAR` would parse as class method calls on package `BAR`. If `BAR` does not have methods named for I/O operators, you get an error; if `BAR` does actually have those methods, they will be called (and they will probably end up throwing errors).	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: On Backwards Compatibility and Bareword Filehandles
by jcb (Parson) on Jul 19, 2020 at 03:50 UTC

The solution is that lexical bareword filehandles exist only in the scopes where they are declared.

Single-word package only need prefixes within the same lexical scope as an identically-named filehandle. The use of a filehandle YAML in one block does not affect YAML as a package name outside of that block.

If I write code with a bareword filehandle in a module, I don't know how that module will be used. I don't know when it will be loaded. I don't know what will be loaded before it and I don't know what will be loaded after it.

This proposal is that bareword filehandles in your module would become lexicals, private to your module.

If the parser parses this construct in different ways depending on what's loaded, it's fragile and undecidable.

This is a misunderstanding. Only lexical declarations affect parsing in this proposal, and open BAREWORD,... becomes a lexical declaration. Within the lexical scope of an open YAML,..., YAML would parse as {I/O}YAML and class method calls on YAML would need to be written as ::YAML->method(...) or method ::YAML (...). However, YAML is a bad example here because it has a functional interface, and YAML::DumpFile(...) (for example) is already unambiguous, even if YAML is a lexical filehandle.

Outside of the lexical scope of open YAML,..., YAML remains a "plain" bareword, and close YAML would, for example, parse equivalently to ::YAML->close — that is, as a class method call on package YAML, whether or not YAML is actually loaded. Obviously, executing a method call to an undefined class is an error, but parsing in this proposal does not depend on the set of loaded packages, only the lexical declarations in effect.

After thinking about this a bit more, is your concern what happens if a module attempts to use a bareword filehandle defined elsewhere? The I/O operations on undeclared filehandle BAR would parse as class method calls on package BAR. If BAR does not have methods named for I/O operators, you get an error; if BAR does actually have those methods, they will be called (and they will probably end up throwing errors).

[reply]
[d/l]
[select]

In Section Meditations