[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: strict.lua
- From: David Manura <dm.lua@...>
- Date: Sat, 31 Mar 2012 01:16:21 -0400
On Fri, Mar 30, 2012 at 4:37 AM, Steve Litt <slitt@troubleshooters.com> wrote:
> Personally, I'm going to use strict.lua every time, and if later I
> perceive a speed problem, I'll take it out and see how much faster
> things go.
Beware that strict.lua breaks Lua compatibility. Not only does it
detect unwanted global side-effects, but it introduces one as well.
Therefore, I wouldn't recommend requiring it in a module intended for
reuse by other programmers.
The Lua Reference Manual allows code to do things like `_G.foo` to
test whether `foo` exists in the global table `_G`. I do things like
that in compat_env [1] for capability testing (in preference to
version testing [2]):
if _G.setfenv then -- Lua 5.1
M.setfenv = _G.setfenv
M.getfenv = _G.getfenv
else . . . end -- >= Lua 5.2
However, if a program loads a module that loads strict.lua and then
the program sometime loads another module, perhaps written by someone
less strict, that does the above, then the latter will fail (unless
protected by pcall, which maybe it should do). For another similar
example, see [3].
If you wanted to improve strict.lua, I think we would prefer to impose
the strict behavior, at least in terms of reads, on _ENV but not
module _G. You may also want to detect various other errors like
math.* functions being misspelled or being passed bad/extraneous
arguments. This can be done locally:
_ENV = require 'strict._G' -- enforce strict global behavior on
this module only
local math = require 'strict.math' -- enforce strict math behavior
to this module only
local x = -1
math.sqrt(x) -- raise error (or, more politely, log warning) rather
than return nan.
Moreover, you may allow overriding `require` or `package.loaders` with
strict behavior out-of-band from the command line ("lua -l" or "lua
-e").
I've thought of implementing such things. Personally, I've moved
toward having the text editor detect such errors immediately, but it
could be useful when running code under a test suite, sort of like
those dynamic memory checkers that replace malloc/free.
[1] https://gist.github.com/1654007
[2] http://lua-users.org/lists/lua-l/2011-11/msg00413.html
[3] http://lua-users.org/lists/lua-l/2009-08/msg00297.html