Norman Ramsey wrote:
Perhaps Lua 5.2 can address the policy disorder by
providing a value 'table.hole' whose sole purpose is to be distinct
from every other value (including nil) :-)
This makes the most sense to me out of any of the other solutions.
Nil in tables is not "nothingness"--it means, technically, that the
key is non-existent. So, asking Lua if a specific table element is
nil is, in essence, asking if that element is non-existent.
Setting a table element to nil specifically is just *telling* Lua
that the element doesn't exist. Lua doesn't handle non-existent
elements because they *don't exist*. So you can't expect to be
able to tell Lua that an element doesn't exist and then have it
know that you meant that the element existed, but was blank.
People use the value 'nil' in such a way as to say "nothing".
'blah = nothing'. But if you're writing that with a nil, you're
telling Lua that blah doesn't exist. A "hole" or "blank" value, as
Norman suggested, addresses this by being able to differentiate
between
t[1] = nil; -- a nonexistant element, and
t[2] = table.hole; -- an element that exists, but has no properly
defined value
#t = 2, because 'hole' is has a value. Of course, I rather think
we could come up with a more friendly name than "hole"--like maybe
"blank". I dunno.
Users can continue using nil if they want, and use all the work-
arounds to have iterators work in sparse tables, which means it's
fully backward-compatible. Nothing changes except the addition of
another element to the table library (as far as I know). Other
users can properly use new functions.
It may also be useful to define a function in such a way that f(a)
is "(a==nil) or (a==table.hole)", so that you can check whether a
value is nil *or* a hole.
As always, I'm not a Lua expert and I don't know what most people
in the community are looking for; this just seems to be a very
simple and elegant solution to a long-lasting problem. Feel free
to get all up in my grill if you disagree--I want to see what
others think.
--
Irayo
