lua-users home
lua-l archive

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


On Sun, Mar 30, 2014 at 4:09 PM, Tim Hill <drtimhill@gmail.com> wrote:

On Mar 30, 2014, at 11:36 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

>
> The effect of this proposal can be achieved easily. The syntax is only
> slightly different: `global {var1=val1; var2=val2}` instead of
> `global var1,var2=val1,val2`.
>
> The Lua way is to provide methods, not policies. This proposal
> involves policy, not method. I do not support it.
>


I disagree with this as a definition of “the Lua way"; if it were then 5.3 would certainly NOT include bitwise operators and we’d just have a bit64 library. Second, a blanket “all policy is bad” argument is rather dubious. SOME policy is both necessary and good; that’s why Lua specifies the precision of floats and (in 5.3) the width of integers (never mind about the compile-time variants).

To my mind “the Lua way” is have as LITTLE policy as is practical. The question, therefore, is really this: is it sufficiently useful to have a policy-based method to manage global variable declaration to justify it’s addition? Notice that this has nothing to do with HOW such a policy is realized. This is because policies solve issues of standardization, while the realization of policies involve issues of efficiency and compatibility (and, dare i say it, elegance).

The OP points out that the problem with existing implementations/work-arounds/hacks (choose your word) is that they all collide with 3rd party code such as libraries. I’ve had this issue as well; it doesn’t really matter what you do with the existing solutions, they only really work if you have total control of 100% of the source in your project.

And, to be blunt, it *is* a wretched nuisance when you spend an hour staring at code that should work only to notice a simple single-letter typo in a variable name was the cause.

I personally don’t agree with the OP’s proposed solution; it feels odd to me. But I *do* agree with the motivation to try to create such a solution.

—Tim

I like strict.lua but I think it should remain as a separate optional module distributed with Lua (whatever did happen to the etc/ dir in Lua's distribution?  someone told me it was last seen in 5.1).

I also take issue with strict.lua's implementation.  From what I remember, the original sets a metatable on _G, which (imo) is destructive/bad.  A better way (for 5.2) would be replacing _ENV with a proxy table that contains two members (_G & _ENV).  This way you can't some_env_global = 'cat' but you can _ENV.some_global = 'cat' and you still have access to _G for "really really globals" (haha).  I dunno, I just squirm at the thought of anything setting a metatable on _G, it feels sinful.

PS: The proxy table should define __newindex/index (of course), but also __len, __pairs, __ipairs, and __eq -- that should cover the common cases of how _ENV might be used.

PPS: It's important to remember that _ENV is strict.lua's _G. :>