[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Undefined variables returning nil
- From: Andrew Starks <andrew.starks@...>
- Date: Wed, 20 Mar 2013 12:07:49 -0500
William's points have validity, and they're very reasonable ones,
especially given that he's looking from the outside in, pointing out
things that happen to be true: miss-typing something leads to nil
values that are hard to catch, etc. Others more eloquent than I have
pointed out how this reality is part of programming in Lua and for it,
things work really well.
One area that has me typing too much repetitive code is this:
if not t.attribute then print("hi!") end
soooo.... that's different than:
if not t.attribute == nil then ...
...because t.attribute could be set to boolean false. So if I want to
know if it's there and false:
if t.attribute ~= nil and not t.attribute then .... end
This gets back to something I've brought up before which is some kind
of "exists" shorthand that de-obfuscated the difference between
"false" and "not there". But, you know, it's fine the way that it is,
too.
On another, related, topic, this code is often useful:
local ret, err
do
ret, err = myfunc()
....
end
it's not too clear why from my example, but basically, assigning "ret"
and "err" to the local scope, without putting anything in them, is
nice when you need them to survive through inner-blocks, but you don't
want them global. Usually this is relevant when you're assigning them
conditionally and/or in multiple places.
I think all dynamic languages have some form of the realities that
William observes. If there is any detected annoyance, we apologize. I
believe it stems from A) we've been over and over and over this and B)
we don't see them as problems, only realities resulting from the
design of Lua.
It just means that you do more argument checking explicitly and have
more freedom to be flexible WITH very fast execution, because of it.
-Andrew