R: Re: Re: How to export associative arrays to an embedded lua script?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: R: Re: Re: How to export associative arrays to an embedded lua script?
- From: "linuxfan@..." <linuxfan@...>
- Date: 2015年10月12日 17:35:53 +0200 (CEST)
Thank you, the fog is almost gone (but not completely...).
>> Store
the table name in the metatable). Nice and straightforward, I
>> have
to think about it.
>
>This means you need to have one metatable per
table. This is overkill.
This is not as overkill as it seems. There
are only 7-8 tables, it is not a lot of memory. When a script accesses
a table, a metatable lookup is done, anyway. One metatable or another
makes no difference. Then the __index handler is called, anyway - again
makes no difference. The handler then looks up the pascal table name
(or, better, a pointer to it). Apart from a little more memory, I see
no differences in storing a link to my table in the table itself, in
its metatable, in an upvalue (meantime I have understand what they
are), or in the registry. The simplest thing is to store a pointer to
the table in the table itself: it uses nothing else; there is not risk
of collisions because scripts will use these tables only with well-
known keys. Storing the pointer in the metatable instead of the table
adds a passage: instead of "handler has the table, lookup in that
table" it becomes "handler has the table; get the metatable; lookup in
the metatable".
>
>> (2 Map a value->tablename in the registry).
>>
Doesn't work if it is true that reference to a table can become
>>
invalid.
>
>Lua references cannot become invalid. It's only C pointers
to these
>values that can become invalid. So this works fine.
I would
like to cut it short. When I create a lua object (table) in this way:
lua_newtable(L);
lxEnviron := lua_topointer(L, -1);
luaL_setmetatable
(L, 'xplcmetatable');
lua_setglobal(L, 'env');
...I read the value
lua has put on the stack via lua_newtable(). I store this value in my
variable lxEnviron; it is the same value lua stores in its global table
via lua_setglobal(). Now there are only two possibilities:
1) The
value of GLOBAL["env"] always stays the same, and it always refers to
the table named "env". This unless a malicious / broken lua script
redefines "env".
2) For some reason, but not voluntarly by a script,
the value of GLOBAL["env"] can change, still remaining a valid
reference to the table "env". So, since that moment, lua still works
well with its global table referring correctly to the table "env", but
the value I stored in my variable lxEnviron is old and no more valid.
For me it is hard to believe that case #2 can happen, but I don't put
my hand on the fire.
>From what I've read of your problem I don't see
any reason not to use
>full userdata to represent your objects.
Ok, I
will give it a try, so I will be able to judge by myself. Thank you
Jerome and all the others, and regards,
Linuxfan (aka Doriano)