 |
lua-l archive |
|
|
||
|
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