Re: [proposal / postulation]: global keyword that works with lua as config file

[Philipp Janda <siffiejoe@...>]

Am 31.03.2014 18:46 schröbte David Favro:
> It might be possible to try to load modules using their own private
> environments, which aren't strict-protected, but aside from being a PITA
> [require() has no environment parameter, I guess loadfile() would be
> needed], I suspect that this will introduce a lot of other problems.

You could modify the lua searcher. See e.g. here[1]. But you are right, 
it's not without new problems ...

> The same problem arises when creating modules, only inverted: if I
> require("strict") from within my module-definition (unless I take
> special precautions to put my module into its own environment), I am
> likely to break any code which require()s my module, if it ever sets a
> global -- so it's effectively verboten to do so from anywhere within a
> module, and (static analysis tools aside) it's difficult to detect
> subtle bugs in my module due to a forgotten 'local'.

I think the whole point of the proposal was that the OP likes to use 
`strict.lua` and *is aware* that it breaks in some cases. One way to fix 
that would be to make all Lua code compatible with `strict.lua`, 
especially the declaration of wanted globals. If all code declared 
globals in a compatible way, it wouldn't matter that `strict.lua` 
affects third party modules.

> So, I suggest that any proposed innate strict-global feature should have
> some mechanism to (perhaps optionally) only be enforced for accesses to
> the global environment from the chunk in which it is specified; _STRICT
> as proposed does not respect this.  Thinking along these lines, what I
> think might be more useful than throwing runtime errors, and perhaps
> even easier to implement, is a mechanism to specify default-local rather
> than default-global for names declared _just_ within a particular
> chunk.  Either or both would be welcome.

Locals at the wrong scope level are bugs as well. They might occur less 
often, but they are a lot harder to find using static analyzers. So in 
combination with the other draw-backs of local-by-default, I don't think 
that would be a good solution.

> -- David

Philipp

  [1]: https://github.com/siffiejoe/lua-modjail