Miles Bader <miles@gnu.org> writes:
That's exactly my point. That code is the clear and natural way
to use
{...}, but it also breaks whenever any of the args in ... is nil.
No it doesn't (I tried it)...
I take this back -- I tried some more test cases, and it _sometimes_
works (with nils), but sometimes doesn't. Specifically, in runs
into the
weird behavior in Lua with respect to "#t".
So the main issue is keeping track of the number of arguments, you
can't
just use #{...}.
For the case of immediate argument processing, it seems to me that
select is OK -- it's not as pretty as {...}, but it's probably more
efficient.
For the case where you want to bundle up the args and pass them to
another function for processing, I guess you've got to pass in the
number of arguments explicitly, or record them in the "arg table"
({...}) using a non-integer key.
Luckily that sort of thing can be encapsulated in handy
functions... :-)
E.g.:
# handy function
function argvec(...)
local args = {...}
args.num = select ('#', ...)
return args
end
Then:
function bar (...)
local args = argvec(...)
for i = 1, args.num do
print (tostring(i).."\t"..tostring(args[i]))
end
end
seems pretty nice :-)
[FWIW I don't really like the "nil value means delete" behavior of Lua
either; I wish Lua had an explicit table delete operator, and treated
nil as a normal value. So I'd support adding a new table type that
had
these properties. OTOH, I'd also like a bunch of other little changes
(e.g. more flexible behavior to allow natural use of 0-based arrays),
and I guess it's unlikely most of them will ever end up in the
official
language ... :-]
-Miles
--
We are all lying in the gutter, but some of us are looking at the
stars.
-Oscar Wilde
