Re: Say No to global-by-default

[Pierre Chapuis <catwell@...>]

> This is not a very useful advice when you deal with code written by
> someone else. Global as default and similar things are *obviously* no
> such big deal when you live in a vacuum and don't deal with other's
> people code. Then you have to just apply good discipline and you're safe.
> 
> Unfortunately, based on some replies in this ML, it looks like many
> people really don't understand problems that appear only when you have
> experience from working with someone else's code, trying to understand
> it, debug it or refactor...

Several posters here seem to be under that impression, so let me clarify. I made a presentation [1] which talked about that at Lua Workshop 2013. As you can see from the slides about "quality", I am aware of the problem. I still don't think this proposal is a good idea.

There are three main kinds of code in Lua: module code, application code and "scripting" code (configuration, etc). They have different requirements.

If someone writes a module (in Lua) that writes to the global namespace, you can easily detect it with existing tools and report it to them. If they don't fix it, you should consider why you are depending on poorly maintained modules. For what it's worth, I am maintaining a growing production code base of Lua code, and our build step fails unless luacheck passes on *all* the Lua code we ship, including dependencies (we do have selected exceptions in .luacheckrc).

If you use Lua as a scripting language and want to disallow globals in code written by users of your application, you can. Just sandbox them, and if you really want them to use locals only, set a metatable on their _ENV and make it read-only.

[1] http://files.catwell.info/presentations/2013-11-lua-workshop-lua-ecosystem/