Re: Replacement for unlocked refs?

["J. Perkins" <jason@...>]

But really two tables are required, right? One for locked refs
and another for unlocked? And then the reference value must also
indicate which table it is stored in, by using negative numbers
for unlocked refs or something like that. Doable, but really ugly.
However it is actually implemented, this should be, IMHO, a part
of Lua itself and not something the end-user should have to write.

Is there some reason why unlocked refs were dropped?

Jason




Roberto Ierusalimschy wrote:

> On Thu, 31 Jan 2002, J. Perkins wrote:
> > If you'll accept my $0.02, the current implementation of
> > ref/unref seems a big hack. The ability to associate C and
> > script objects is an awfully important feature for an
> > embedded language, but the current method (indices into
> > the registry) seems an afterthought. At the very least, a
> > dedicated table should be set aside for refs, freeing the
> > registry for application use, and support re-added for
> > unlocked refs.
>
> In the work version, the old ref/unref are just macros that use
> luaL_ref, luaL_unref, and lua_rawgeti over the registry. These functions
> can operate over any table. So, it is trivial to put your references in
> your own dedicated table (which can be weak).