[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Incorrectness in the manual
- From: Philipp Janda <siffiejoe@...>
- Date: Thu, 7 Sep 2017 00:55:10 +0200
Am 05.09.2017 um 16:23 schröbte Roberto Ierusalimschy:
Lua manual contains very misleading incorrectness.
According to manual, "luaL_setfuncs" SHARES upvalues among all the
When nup is not zero, all functions are created sharing nup upvalues, which
must be previously pushed on the stack on top of the library table.
(end of quote)
But that's not true.
Actually, each function gets its own separate upvalues.
These upvalues are initialized with the same values, but upvalues are NOT
SHARED between functions.
This is very confusing.
For example, one could think after reading the manual that using
"luaL_setfuncs" it is possible to register set of two functions: "set" and
"get" sharing the same upvalue, which is being set and get.
But this direct solution will not work. Instead, some workaround is
required (such as using a container holding the shared value).
Actually, for your interpretation, one would need to find a way to
push an upvalue in the stack.
With a new internal type tag (e.g. LUA_TUPVAL) the lightuserdata
pointers in the TValues in the CClosure upvalues could be (ab-)used to
point to UpVal structures similar to how Lua closures do it. The normal
TValue upvalues in a C closure could be changed on demand when the
upvalue is target of a `lua_upvaluejoin` call. `luaL_setfuncs` could do
that for all its functions and upvalues, or we could add a new `luaL_`
API function that really creates C closures with shared upvalues, or we
let developers handle it manually when it's really needed. Anyway, there
would be no need to push an upvalue to the stack.
Did you really understand that way?
Has someone ever done?
There was a stackoverflow question regarding shared upvalues of C
closures a few days ago, and I found an old mailing list thread from 2006.