Re: [Bug report] unpack()ing multiple tables does not behave as expected
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [Bug report] unpack()ing multiple tables does not behave as expected
- From: ddneilson <ddneilson@...>
- Date: 2008年5月16日 10:42:54 -0600
I can definitely see the performance benefit if you're only interested
in passing the first return value of a function to another function and
don't want to create a local variable -- saves a bunch of unpack({
function(...)}, 1,1) calls which'll construct a temp table, and saves a
variable lookup when capturing that first arg with "local x =
function(...)" just to pass it as a function arg in the next code-line.
Though, I'll admit, I don't see how it saves "{ if (lua_gettop(L) > 3)
luaL_error(L, "too many arguments!") }" code within the lua libs. Other
than the inefficiencies of pushing more args onto the stack than a
function needs, does it really matter if you pass 15 arguments to a
function that only wants/needs 3? It can just silently ignore those last
12 args.
<quote>..but more importantly you can use function calls inside a
parameter list to another function and not worry that'll it return a
bunch of values clobering yours.</quote>
Presumably if you're calling a function that returns multiple
arguments, you know how many return values it has and can adjust
accordingly; even if you don't have an exact number, you can wrap it in
"unpack({function(...)}, 1, n)" in the worst case. If that's too
inefficient, due to table construction, then add a new function to Lua
-- firstn(n, ...) returns up to the n arguments 2 through n+1 -- then
just use "firstn(1, function(...))"
<shrug>
I guess I just don't see how having inconsistent behaviour is
desirable; the behaviour being defined this way doesn't make it any less
inconsistent. function(...) pushes all of its return values onto the
stack; but, if you call another function before popping the stack then
you lose all but the first return value. Seems so very strange.
I'm sure there was a long discussion that resulted in this behaviour,
so I'll accept it and kludge around it; just wanted to voice my opinion. ;-)
-Daniel
Alex Davies wrote:
It may seem strange at first, but the benefits are large. There's the
performance aspect, but more importantly you can use function calls
inside a parameter list to another function and not worry that'll it
return a bunch of values clobering yours. The last argument is allowed
to overflow - there's a reason you don't see a bunch of { if
(lua_gettop(L) > 3) luaL_error(L, "too many arguments!") } in the lua
libraries. :)
- Alex
From: "ddneilson" <ddneilson@gmail.com>
Hm, so it is. It's such an odd behaviour (read: counter intuitive to
me) that I honestly didn't think for a second that it was actually
intentional! <shrug>