[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [proposal / postulation]: global keyword that works with lua as config file
- From: David Favro <lua@...>
- Date: Mon, 31 Mar 2014 12:46:49 -0400
On 03/30/2014 01:57 PM, Andrew Starks wrote:
I'm not sure I agree that it works well: it is problematic in that it
doesn't support name scoping, by which I mean this will raise an error:
`strict` is available and works well.
local foo = require("foo"); --< a global is set in the module definition
As a user of module "foo", I have no way of knowing if it pollutes the
global namespace or not, and I've found that some popular ones do. If I
require() all of my needed modules prior to require()ing "strict", I am
still not safe:
local foo = require("foo");
local bar = foo.bar(); --< global is set in this function
Again, as a user of module "foo", I have no way of know if and when it will
set a global, and once I require("strict") no module is usable that doesn't
promise to never set a global as part of its "contract".
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.
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'.
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.