Re: C API question

Subject: Re: C API question
From: liam mail &lt;liam.list@ ... &gt;
Date: Fri, 7 Jan 2011 23:20:20 +0000

On 7 January 2011 22:34, joshua simmons <simmons.44@gmail.com> wrote:

What about use-cases like https://github.com/jsimmons/LuaSharp/blob/master/LuaSharp/LuaFunction.cs

You could put your own table in the registry I suppose.

On Thu, Jan 6, 2011 at 5:41 PM, Ralph Hempel <rhempel@bmts.com> wrote:

On 01/07/2011 10:59 AM, Roberto Ierusalimschy wrote:

I would be happy to see refs go away because they seem like a sharp,
tempting feature that actually doesn't add value.

If your userdata object needs to reference other Lua data, you
really, really, really want to use the environment mechanism because
this works with the GC whereas refs are very prone to creating
uncollectable cycles.

If your C code needs to reference a Lua value, I tend to recommend
using light userdata keys in the registry bearing in mind that this
creates anchors for the GC.

Exactly. The archetypal use of references were a full userdata keeping
references to other Lua values by keeping in its C structure the
integers returned by luaL_ref. The finalizer for this userdata should be
responsible to release its references when the userdata was collected.
This kind of use became obsolete with environments.

Does anyone still use references in real applications? For what?

The IUP source code is full of lua_ref() and friends...

Ralph

As I was saying on IRC Joshua, you can put your own table into the registry but then you add a global dependancy (possibly and yes I know LUA_REGISTRYINDEX is a macro and therefore global but we live with that) for the table ID then we still need an ID into the table for an entry. This I imagine would probably involve rolling your own ID system, maybe a pool of ID's which can be reused and where is this pool going to be stored back in the table? Ok so we need an ID for that as well.