It's declared and defined in the function argument list, assigned nil if no argument is passed for it. The problem with prohibiting the access of undefined globals is that your tables remain unprotected. If the value of "extent" was retrieved from a table argument using an incorrect key, the mistake would go unreported.
>It's declared and defined in the function argument list
No, it isn't. No value is ever assigned to "extent" if the function gets called without a second argument. "extent" is nil just like all other non-existing objects are nil.
It is a common newbie mistake to treat Lua's nil as the equivalent of a null pointer or some kind of "nothing value" you find in other languages.
Lua's nil is not a value of any kind. "object = nil" means "delete object" not "set object to nothing value". Because of that you should never assign nil to anything unless you actually want to delete it. Delete as in "garbage collector please pick this up". E.g.
character.armor = NULL
in C does not delete the armor field of the character struct.
character.armor = nil
in Lua does.. and you probably don't want that in such situations because if you handle it this way you create countless unnecessary allocation, reallocation, and deallocation operations behind the scenes. If you just mean "nothing here right now" you should set the field to "false" or some specific nothing value.
>If the value of "extent" was retrieved from a table argument using an incorrect key, the mistake would go unreported.
That is correct and a problem indeed. However, in my experience such things rarely happen and the resulting bugs are easy to find.
> No, it isn't. No value is ever assigned to "extent" if the function gets called without a second argument. "extent" is nil just like all other non-existing objects are nil.
If you prefer the Lua concept that all possible elements start out pre-set to nil, then again, "extent" is already defined. Whichever mental approach you prefer, the variable "extent" exists in your example.
> Lua's nil is not a value of any kind. "object = nil" means "delete object" not "set object to nothing value". Because of that you should never assign nil to anything unless you actually want to delete it. Delete as in "garbage collector please pick this up". E.g.
This isn't correct. Nil is a value type, and it exists solely to be different from any other value. Lua tables are presented as containers in which every possible key starts out already assigned the value of nil. Nil doesn't explicitly mean "delete object". Rather, a table variable is a reference to a table object, so assigning it a value of nil removes the reference and makes the object available for garbage collection (if nothing else is referencing it).
In other words, the reason Lua makes no distinction between non-existent elements and elements assigned to nil is that, conceptually, every possible element already exists and starts out assigned the value of nil. Therefore, when I use the term "non-existent", I'm speaking in practical terms from the perspective of the programmer. You presented to me an example which you claimed would no longer work under the behavior I proposed, but the "extent" variable would be both declared and defined in the function's argument list, so the "default argument" behavior would still work. The variable would just be assigned the value of nil if no argument was passed for it.
I'm not sure why you're offering these explanations except to make it appear as if I don't know Lua. I presume you're the one who voted down my previous comment.
> That is correct and a problem indeed. However, in my experience such things rarely happen and the resulting bugs are easy to find.
To the response that it just doesn't happen that often or that the bugs can be easily fixed, I would point out the existence of several Lua static analyzers and direct you to Google's own analyzer (http://code.google.com/p/lua-checker/), with this project description:
"Lua is dynamically typed, with a simple type model. Variables can be assigned values of any type. This makes development of small scripts somewhat easier, but it means that in larger programs many common programming errors are not detected until run time. For example:
- Referencing a variable that has not been declared will return nil. This is no different from referencing a 'declared' variable that has the value nil. Thus spelling mistakes in Lua variable names can go undetected and lead to program misbehavior.
- Tables (Lua's main data structure) are not typed, so any table can contain any keys. When tables are used in a manner similar to C structures, spelling mistakes in field names can go undetected and lead to program misbehavior.
- Function arguments and return values are also untyped and have similar problems.
In practice, Lua programs over (say) 1000 lines tend to accumulate these kinds of problems, making debugging difficult."
