R: Re: Re: How to export associative arrays to an embedded lua script?

["linuxfan@..." <linuxfan@...>]

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)