Re: extended lua value type question

[Peng Zhicheng <pengzhicheng1986@...>]

On 11/07/2014 07:59 PM, Chris Cummings wrote:
> Hi there
>
> We’ve extended LUA to support some new value types to store vectors and quaternions in to make it a little better for maths. Along the way, as these new value types contain fields (vec.x, vec.y, etc), we modified the gettable function to read these properties from the lua value. This basically means luaV_gettable now contains an case in its type check statement that says ‘else if ttisvec(t)’, check the field requested and return it (so mynumber = myvec.x or mynumber = myvec[0] work). A lot of this was based off the approach of the existing experimental luavec library.
>
> However, on modifying luaV_settable in the same way, we noticed the value passed into the function is const:
>
> voidluaV_settable (lua_State *L, const TValue *t, TValue *key, StkId val) {
>
> It then gets cast to a none-const table in the table case.

I guess you read it wrong. the cast applies to the value part of the table entry instead of the table itself.


> Does anybody have any experience modifying these bits, and any idea as to whether it’s safe to cast away that const so that our lua code can write to the value (allowing myvec.x = 10 for example), or is there a good reason that value is read-only.
in Lua table is one of the ``object'' types, which means tables have reference semantic. this function do modify the
table object (which is heap allocated and not constant), but it never modify the TValue itself (which is a stack slot or
VM register, thus the const qualifier),.

for your extended types, I personally suggest using metamethods instead of changing the handling of the VM opcode.
the global state stores a metatable for each type (except table and userdata).
see the definition of global_State[1] and luaT_gettmbyojb[2]


[1] http://www.lua.org/source/5.2/lstate.h.html#global_State
[2] http://www.lua.org/source/5.2/ltm.c.html#luaT_gettmbyob