[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Observations/Questions
- From: Ken Rawlings <krawling@...>
- Date: Thu, 8 Jul 1999 16:32:49 -0500 (EST)
On Thu, 8 Jul 1999, Luiz Henrique de Figueiredo wrote:
> you have to be careful if you're keeping a list of lua_Object.
> you should keep a list of references instead and still be careful unless
> you lock everything.
While thinking through possible list API's, one idea I had was to
just let Lua have access to raw listNode pointers. However, I haven't
been able to figure out how to do the equivalent of lua_ref() going
the other way. What is the method for having Lua let your C library
know that it's holding onto a reference, and then let you know when
that reference is released?
Using tagmethods for gc and setglobal would seem to be the answer, but
things could easily get out of sync when local varibles are used.
That brings up a question i've been wondering about for a while --
why are there no setlocal/getlocal tags?
Also, is there any documentation at all for the lauxlib functions?
They look quite useful, but I can't find any documentation and there
aren't comments in lauxlib.c describing what they do.
> > list_remove(listPointer, int index)
> if listPointer is the head, how would these not be O(n)?
I've started working on a list API more like the following:
lua_Object listAppend(LuList*, lua_Object)
lua_Object listAt(LuList*, int index);
lua_Object listReplace(LuList*, lua_Object);
Where the idea is that the LuList* has a notion of the "current"
list position, and listPrevious(), listNext(), listBegin(), listEnd(),
listAppend(), and listRemove() are all O(1). listAt() is still
O(n), but it's mainly a convenience function anyway.
One of the tradeoffs in this API is that lua "nil" values can't be
stored in a list(they're returned by listNext(), etc. to denote the
bounds of the list), but since "nil" isn't a valid value to store in
a Lua variable anyway, this seems reasonable.
Speaking of which, add me to the list of people who think that Lua
really needs a boolean type. The whole "nil" issue for expressions
makes me really uncomfortable with what is otherwise a really clean
_Ken Rawlings (firstname.lastname@example.org)