lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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