Re: Some small requests for the next release

[Russell Smith <russ.ls@...>]

> 4) The issue of accessing nested tables comes up on a regular basis.
> Doing so in the API is tedious, so
>     I am sure everyone has rolled their own equivalent of:
>            lua_gettablepath(L, arg, "key1", "key2", ..., NULL)

i used to do something like this but found that it didn't really save
that much pain (i.e. it's not so flexible). i've settled on a solution
that lets me embed snippets of Lua code in my C++, like this:

    int index = 3;
    const char *string = "blah";
    luaDo (" foo.bar[a1] = a2 ", index, string)

the first time the luaDo() is encountered the string is compiled.
subsequent times the compiled function is looked up in a registry
table, so it's generally about as fast as a lua_gettablepath() kind of
solution. various C++ mechanisms handle detecting the types of the
arguments and pushing them appropriately to the lua stack, and there's
also a simple way to return values to C++ variables.

russ.



On Thu, 24 Feb 2005 12:18:52 -0400, nt <niklas@ibl.bm> wrote:
> Hello,
> 
> A request for a few small additions to the next release. Forgive me if
> the features are already available--I am using an older 5.0.
> 
> 1) Add 'math.nan' as a constant to the math library.  At the moment, the
> "feature" of doing
>       local nan = tonumber("nan")
>    works, but is inconvenient, probably non portable and hard to
> remember.  Inclusion of the
>        if v ~= v then ---is nan
>    mechanism in the reference manual  would also be nice in lieu of a
> math.isnan
>    Obviously issues arise when numbers are not reals---I suppose
> something such as MAXINT could
>     be returned for the integer case.
> 
> 2) Perhaps I am missing something, but there does not appear to be a
> convenient way to determine if a
>    table is empty.  Perhaps a 'table.isEmpty(t)' function could be
> added or even
>     local arraysize,haveHashes = table.stats(t)
>    which would reveal something about the internals of the table (i.e.
> how much is allocated to array
>     and whether it is a pure array). Handy for estimating likely heap
> size in test situations.
> 
> 3) Some way to access file handles in C code.  At the moment I have to
> look at the io library source
>    and see that the file handle userdata is a "FILE*" and put in check
> and caste code accordingly.
>    Probably not portable in general.  Something like
> 'luaL_tofilehandle(L, arg)' might be helpful.
> 
> 4) The issue of accessing nested tables comes up on a regular basis.
> Doing so in the API is tedious, so
>     I am sure everyone has rolled their own equivalent of:
>            lua_gettablepath(L, arg, "key1", "key2", ..., NULL)
>     using varargs.  Would be nice to standardize this as a convenience
> function.
> 
> 5) Please, please add a section to the Reference Manual documenting the
> functions in lauxilib.h. Would
>     make it much easier to get up to speed on what routines are
> available.  While I am on the subject,
>     it would also be nice if this was called 'luaaux.h' or something
> with 'lua' at the front as that would
>     lessen the likelihood of collisions with other e.g. Linux include
> files in future OS releases.  Even
>     better would be something like:
>          #include <lua/core.h>
>          #include <lua/lib.h>
>          #include <lua/aux.h>
>     but that is rather Unix specific and makes it a little harder to
> have competing versions installed.
> 
> thanks,
> niklas
> 
> 


-- 
Russ Smith
http://www.q12.org/