lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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:

   LuList*     listCreate()
   lua_Object  listAppend(LuList*, lua_Object)
   lua_Object  listRemove(LuList*);
   lua_Object  listPrevious(LuList*);
   lua_Object  listNext(LuList*);
   lua_Object  listBegin(LuList*);
   lua_Object  listEnd(LuList*);
   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
   language.

_Ken Rawlings (krawling@bluemarble.net)