 |
lua-l archive |
|
|
||
|
Am 30.03.2014 23:16 schröbte Andrew Starks:
If 5.3 has new keywords, then global is just one more parser issue to trap, so it's not a big deal to trap this one too.
So far 5.3 doesn't have new keywords. It has new bitwise operators, but luckily most modules/programs can live without those. Undefined globals are more common (at least in my code), e.g. unpack, setfenv, loadstring, jit. (I recently looked at some OO modules, and some of them still put classes in the environment table.)
2: _STRICT is a value that is global and defaults to `false` (or nil, but one must be able to assign it globally).Why not just preload `strict.lua` instead?!I can do that. My point is that a natural method would make it more pervasive and less likely to be imemented in conflicting ways.
It would be `require( 'strict' )` vs `_STRICT = true`. The first one is already pervasive (and quite natural) for all people using `strict.lua`. And what's wrong with conflicting implementations (as long as you use only one at a time)?
Then people can `require` it if they want to. But I'd rather use somethingthat works offline (at compile time), or at least can be enabled/disabled on a per-chunk basis (maybe as a fallback to the offline tool). I think that my suggestion achieves that with _STRICTI might be missing something, though.
The value of a global variable is a dynamic thing, so it is not restricted to a certain chunk. You would need something like:
local old_STRICT = _STRICT
_STRICT = false
local val = mod.func() -- call function in a non-strict module
_STRICT = old_STRICT
and that would disable strict checking for all functions called via
`mod.func()`, even the ones defined in a "strict module".
You could make something like `require 'strict'()` work per-chunk using the same techniques as the infamous `module` function. It would still be redundant for me because I use static checking anyway, but at least it wouldn't get in the way ...
Philipp