|
|
12
|
|
Why are people so afraid of globals?
Maybe it is just my age, but this entire discussion sounds a lot like trying to do nasty things to the language to protect inexperienced people from shooting themselves in the foot. Which is an activity bound to fail due to fools being so ingenious.
A few months back I ported a rather large distributed application that was originally written in javascript to lua. In it, we make extensive use of global name space objects, ( which are truly global as the objects's full name actually specifies which sever around the world it actually lives on). Within each object, all state is represented within the properties of the object itself. If you happen to need a temp variable for a particular task, you create a property of the object itself to hold it. Each object is encapsulated, and has its own internal event queue to manage scheduling. Globals do not necessarily impede modularization and encapsulation, poor design, lack of style, and insufficient attention to detail definitely do.
If you take a peek at how Self implements globals, and copy that you'd probably address 100% of the problems people actually have with globals. But lua's OO features aren't quite up to Self's snuff.
Dave
|
|
|
I'm not sure why. In my case, they're great for newbie scripters (who just want to use the language to accomplish some simple goal with help of scripting) - their variables work across a variety of inputs/outputs they can interact with since they're global to the state.
|
|
|
On 2010-07-08, David Goehrig < [hidden email]> wrote:
> Why are people so afraid of globals?
>
> Maybe it is just my age, but this entire discussion sounds a lot like trying
> to do nasty things to the language to protect inexperienced people from
> shooting themselves in the foot. Which is an activity bound to fail due to
> fools being so ingenious.
>
> A few months back I ported a rather large distributed application that was
> originally written in javascript to lua. In it, we make extensive use of
> global name space objects, ( which are truly global as the objects's full
> name actually specifies which sever around the world it actually lives on).
> Within each object, all state is represented within the properties of the
> object itself. If you happen to need a temp variable for a particular
> task, you create a property of the object itself to hold it. Each object is
> encapsulated, and has its own internal event queue to manage scheduling.
> Globals do not necessarily impede modularization and encapsulation, poor
> design, lack of style, and insufficient attention to detail definitely do.
>
> If you take a peek at how Self implements globals, and copy that you'd
> probably address 100% of the problems people actually have with globals.
> But lua's OO features aren't quite up to Self's snuff.
>
> Dave
>
> --
> -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/>
It really isn't about preventing people from shooting themselves in
the foot, but just making it a little harder to do so by accident, and
helping prevent bugs in one module from breaking some completely
different part of your program due to variable name conflicts.
Globals are often said to be a bad thing in most languages, for
various reasons such as efficiency and namespace pollution/conflicts.
With Lua the conflict issue is more severe because there's no compiler
to tell you this name is already used elsewhere (and not even static
typing which might warn you right at the time of conflict if the types
happen to differ).
As some have pointed out, global-by-default (really,
anything-by-default) also makes for some scope ambiguity - assignment
to a global and declaration of a local are syntactically identical.
But this is more of an argument for explicit declaration than against
the use of globals or default scoping.
--
Sent from my toaster.
|
|
|
On 9 July 2010 10:03, Vadim Peretokin < [hidden email]> wrote:
> I'm not sure why. In my case, they're great for newbie scripters (who just
> want to use the language to accomplish some simple goal with help of
> scripting) - their variables work across a variety of inputs/outputs they
> can interact with since they're global to the state.
>
Personally I liked being able to use globals before I learned how
lexical scoping worked. They are definitely easier to use for
beginners, which I think is part of why Lua is easy to learn. I would
advise beginners to give their variables unique names of course.
Though if I "pollute the namespace" with a global called "a" or
"count", it’s only 50% my fault :-)
Vaughan
|
|
|
The solution to name spaces in general is to get rid of the
concept of globals entirely, and make it possible to pass a pointer to
the namespace of a chunk or module, requiring that a modifier be used
to refer to all such pointed to namespaces. Any variable created in a
chunk or module would be local by definition. If a variable is declared
as local, then it would not be visible to any other module or chunk. If
you wish to use a local copy of a variable from another chunk or
module, you would precede the reference with a "l." or even the "$".
Now I haven't completely thought this version of the idea out for lua
and am not a sufficient expert in lua to do so. Removing ambiguity is
the goal and there is far too much ambiguity in functional languages
almost by definition. The guy who wrote about doing things for newbies
merely wants to leverage his experience at the expense of the growth
and usefulness of the language. Some will misuse almost any thing, and
some will just ignore something that is biting them on the nose, but
everything that can be done to clarify a language should be done.
Subtlety is not a virtue unless one is consoling another about
something personal. Subtlety in code is hard enough to maintain by the
person who wrote it, much less the poor benighted soul who must
maintain another person's code.
Everett L.(Rett) Williams II
Vaughan McAlley wrote:
On 9 July 2010 10:03, Vadim Peretokin [hidden email] wrote:
I'm not sure why. In my case, they're great for newbie scripters (who just
want to use the language to accomplish some simple goal with help of
scripting) - their variables work across a variety of inputs/outputs they
can interact with since they're global to the state.
Personally I liked being able to use globals before I learned how
lexical scoping worked. They are definitely easier to use for
beginners, which I think is part of why Lua is easy to learn. I would
advise beginners to give their variables unique names of course.
Though if I "pollute the namespace" with a global called "a" or
"count", it’s only 50% my fault :-)
Vaughan
|
|
|
Vadim Peretokin < [hidden email]> writes:
> I'm not sure why.
what do you think, is it easy to maintain such Lua project with
globals?
> find . -name '*.ds' -exec cat '{}' \; |wc
232853 941638 11438118
--
Yours sincerely, Eugeny.
GM of Enterprise Solutions Department
Doctor Web, Ltd.
http://www.drweb.com, +79119997425
|
|
|
Hi all,
Excuse my ignorance, but C has no namespaces and there's no problem in
building large applications on top of it, right?
I mean, you can always use global variables and use some sort of
discipline in names to avoid nasty problems.
But, hey, I'm a Lua newbie and maybe I'm too naive in this approach.
Cheers,
Antonio
2010/7/9 eugeny gladkih < [hidden email]>:
> Vadim Peretokin < [hidden email]> writes:
>
>> I'm not sure why.
>
> what do you think, is it easy to maintain such Lua project with
> globals?
>
>> find . -name '*.ds' -exec cat '{}' \; |wc
> 232853 941638 11438118
>
>
> --
> Yours sincerely, Eugeny.
> GM of Enterprise Solutions Department
> Doctor Web, Ltd.
> http://www.drweb.com, +79119997425
>
|
|
|
In reply to this post by Everett L Williams II
On Jul 8, 2010, at 10:54 PM, Everett L Williams II <[hidden email]> wrote:
The solution to name spaces in general is to get rid of the
concept of globals entirely, and make it possible to pass a pointer to
the namespace of a chunk or module,
Then all you have done is created a pointer to a globals object and passed it around on the stack rather than leaving it on the heap.
The problem isn't globals, the problem is that coordinating usage of shared resources is hard.
But this isn't a technical or linguistic problem. This is a social/political problem, pretty much THE problem.
My personal opinion is that "globals are bad" is an opinion born out of technical people looking for a technical solution to a non-technical problem.
Dave
|
|
|
On Fri, Jul 9, 2010 at 1:49 PM, Antonio Vieiro < [hidden email]> wrote:
> Excuse my ignorance, but C has no namespaces and there's no problem in
> building large applications on top of it, right?
Very true, but C requires everything to be declared up-front. Lua
will automatically declare an unknown variable to be global
(global-as-default), so any misspelling will cause a runtime problem
since the new variable will have the value 'nil'. (Perhaps it
wouldn't be so bad if the initial value was something like
'undefined').
It's a question of scale. A 100-line script does not have to worry
too much about locals and globals, but a 100Kloc program has to be
more careful, especially with global-as-default.
steve d.
|
|
|
> Very true, but C requires everything to be declared up-front. Lua
> will automatically declare an unknown variable to be global
> (global-as-default), so any misspelling will cause a runtime problem
> since the new variable will have the value 'nil'. (Perhaps it
> wouldn't be so bad if the initial value was something like
> 'undefined').
>
> It's a question of scale. A 100-line script does not have to worry
> too much about locals and globals, but a 100Kloc program has to be
> more careful, especially with global-as-default.
With "local-as-default", a misspelling in the *use* of a variable
will also give you a nil value, which I think is close enough to
'undefined'. In my view (and in my experience), this is not a big
problem. Undefined variables are easily detected in basic tests.
Moreover, as others already pointed out, misspelling may also happen
when accessing table fields (e.g., math.coz), with the same consequences
of misspelling in the use of globals; so, solving misspelling problems
only for globals will not improve much the situation, and solving
misspelling problems for table accesses is completely out of Lua scope.
The problem that concerns me is assignment to globals meant to be
locals, either because someone only forgot to add 'local' or because he
knows no better. This kind of bug is easy to write and hard to find.
-- Roberto
|
|
|
On 9 July 2010 14:18, steve donovan < [hidden email]> wrote:
> On Fri, Jul 9, 2010 at 1:49 PM, Antonio Vieiro < [hidden email]> wrote:
>> Excuse my ignorance, but C has no namespaces and there's no problem in
>> building large applications on top of it, right?
>
> Very true, but C requires everything to be declared up-front. Lua
> will automatically declare an unknown variable to be global
> (global-as-default), so any misspelling will cause a runtime problem
> since the new variable will have the value 'nil'. (Perhaps it
> wouldn't be so bad if the initial value was something like
> 'undefined').
>
In my opinion, it would. I really dislike the distinction between
"nothing" and "nothing" in Javascript.
> It's a question of scale. A 100-line script does not have to worry
> too much about locals and globals, but a 100Kloc program has to be
> more careful, especially with global-as-default.
>
I think I wouldn't mind a 'global' keyword which imports selected
variables from the global environment, similar to (shudder) PHP.
Matthew
|
|
|
On 2010-07-09, Matthew Wild < [hidden email]> wrote:
> On 9 July 2010 14:18, steve donovan < [hidden email]> wrote:
>> On Fri, Jul 9, 2010 at 1:49 PM, Antonio Vieiro < [hidden email]>
>> wrote:
>>> Excuse my ignorance, but C has no namespaces and there's no problem in
>>> building large applications on top of it, right?
>>
>> Very true, but C requires everything to be declared up-front. Lua
>> will automatically declare an unknown variable to be global
>> (global-as-default), so any misspelling will cause a runtime problem
>> since the new variable will have the value 'nil'. (Perhaps it
>> wouldn't be so bad if the initial value was something like
>> 'undefined').
>>
>
> In my opinion, it would. I really dislike the distinction between
> "nothing" and "nothing" in Javascript.
>
>> It's a question of scale. A 100-line script does not have to worry
>> too much about locals and globals, but a 100Kloc program has to be
>> more careful, especially with global-as-default.
>>
>
> I think I wouldn't mind a 'global' keyword which imports selected
> variables from the global environment, similar to (shudder) PHP.
>
> Matthew
>
I've always thought PHP's method was somewhat backward. It can be
confusing for newbies, and I'm always forgetting to add global imports
as I use them.
(That, and do we really want Lua to be known as "the PHP of embedded
languages"? *shudder*)
--
Sent from my toaster.
|
|
|
Antonio Vieiro < [hidden email]> writes:
> Excuse my ignorance, but C has no namespaces and there's no problem in
> building large applications on top of it, right?
no. C requires variables being declared, Lua doesn't. that's the
problem. just one typo and you have a nightmare
--
Yours sincerely, Eugeny.
GM of Enterprise Solutions Department
Doctor Web, Ltd.
http://www.drweb.com, +79119997425
|
|
|
In reply to this post by Roberto Ierusalimschy
On Jul 9, 2010, at 7:00 AM, Roberto Ierusalimschy wrote:
> The problem that concerns me is assignment to globals meant to be
> locals, either because someone only forgot to add 'local' or because he
> knows no better. This kind of bug is easy to write and hard to find.
The Smalltalk and Ruby fix for that: Variable name formatting determines the namespace in which to look.
This causes a certain amount of shuddering when I think about it, but it does mean that globals look like globals and locals look like locals. I think it also has precedence in Common LISP's format for naming dynamically scoped variables.
But it also fights with the various environment switching techniques like module(). That, however, gets us back to the observation that the 5.2work3 change to use the _ENV variable makes it clearer in the code what code is working at chunk scope and what code is working in some other environment.
Mark
|
|
|
On 09/07/10 16:41, eugeny gladkih wrote:
> Antonio Vieiro< [hidden email]> writes:
>
>> Excuse my ignorance, but C has no namespaces and there's no problem in
>> building large applications on top of it, right?
>
> no. C requires variables being declared, Lua doesn't. that's the
> problem. just one typo and you have a nightmare
>
Oh, well, but you can make a typo in a local variable and start using a
global one by accident. A good editor that syntax-highlights local vars
in different colors may be the way to go, right?
Cheers,
Antonio
|
|
|
Another thought...
Say there were a new statement of the form:
global var1, var2, var3
This would mean that we want to access the given names from the environment for the chunk.
Global declarations like this would have the same precedence in lookup as locals. Hence,
local print = function( x ) io.write( x ) end -- [ 1 ]
print( "Foo" ) -- Calls [ 1 ]
global print
print( "Baz" ) -- Calls print as defined in the chunk environment
One could then compile code with the insistence that all variables be declared as either local or global.
But now we can use this in conjunction with the _ENV variable techniques to create alternate global environments. When such an environment is in place -- i.e., a specific _ENV declaration has superseded the chunk environment -- then variable names that cannot be resolved as declared locals or globals are resolved as elements of _ENV.
So, now I can write:
local _ENV = module()
function say_hello()
global print
print( "Hello" )
end
This seems like it points toward something useful, but I'm not sure it's there yet. For example, if I leave out the declaration "global print", this still compiles but now it goes looking for print in the module.
Mark
|
|
|
On Fri, Jul 9, 2010 at 6:32 PM, Mark Hamburg < [hidden email]> wrote:
> function say_hello()
> global print
> print( "Hello" )
> end
Which is how it works in Python, AFAIK. This does have the virtue of
making functions more self-contained and not reliant on a 'local print
= print' somewhere near the top of the module.
steve d.
|
|
|
Hallo,
On Fri, Jul 9, 2010 at 1:21 PM, Mark Hamburg < [hidden email]> wrote:
>
> This causes a certain amount of shuddering when I think about it, but it does mean that globals look like globals and locals look like locals. I think it also has precedence in Common LISP's format for naming dynamically scoped variables.
>
In Common Lisp is just a convention, actually.
--
-alex
http://www.artisancoder.com/
|
|
|
indeed, Ruby's use of special formats for defining variable scope could be seen as rather perlish or ugly but it is in practice an assurance in clear scoping and easily readable code. Perl uses symbol to specify variable type, Ruby uses almost the same symbols for scoping like:
$var # is global @var # is instance var @@var # is class var var # is local 2010/7/9 Mark Hamburg <[hidden email]>
On Jul 9, 2010, at 7:00 AM, Roberto Ierusalimschy wrote:
> The problem that concerns me is assignment to globals meant to be
> locals, either because someone only forgot to add 'local' or because he
> knows no better. This kind of bug is easy to write and hard to find.
The Smalltalk and Ruby fix for that: Variable name formatting determines the namespace in which to look.
This causes a certain amount of shuddering when I think about it, but it does mean that globals look like globals and locals look like locals. I think it also has precedence in Common LISP's format for naming dynamically scoped variables.
But it also fights with the various environment switching techniques like module(). That, however, gets us back to the observation that the 5.2work3 change to use the _ENV variable makes it clearer in the code what code is working at chunk scope and what code is working in some other environment.
Mark
|
|
|
In reply to this post by Roberto Ierusalimschy
On Fri, Jul 9, 2010 at 4:00 PM, Roberto Ierusalimschy
< [hidden email]> wrote:
> Moreover, as others already pointed out, misspelling may also happen
> when accessing table fields (e.g., math.coz), with the same consequences
> of misspelling in the use of globals; so, solving misspelling problems
> only for globals will not improve much the situation, and solving
> misspelling problems for table accesses is completely out of Lua scope.
Usually, most globals are going to be module tables, so this is a fair
point. A smart editor could be taught to handle 'math.coz' as well
(David M's static inspect tools can already do this kind of thing)
steve d.
|
12
|
Locked
