Re: where the 4.0 API isn't better

[Edgar Toernig <froese@...>]

John Belmonte wrote:
> With
> 4.0 we've lost that, and even the simplest representation requires constant
> referencing and dereferencing of objects in the array because the class
> representation could never know when the array might be altered, changing
> the index of the object it represents.

Why that?  Only negative indexes (relative to top) change.  Positive
indexes stay.  Just convert all negative to positive ones using lua_gettop
in your constructor (ie: if (idx<0) idx+=lua_gettop()+1;).

What I don't like has something to do with the new upvalue handling.
IMHO, _every_ C function should call as it's first action lua_settop
with the number of wanted arguments.  That way, they behave the same
as Lua functions regarding missing/superfluous arguments.  But with
the upvalues above the normal arguments this does not work.  You
could do it with lua_insert/remove but that's slow...

IMHO, each use of lua_isnull is wrong as is the test against L->top
in btest() and access().  It's a kludge and easily breaks.  And it
makes C functions different to Lua functions.  The check for defaults
should be made against ttype==TAG_NIL!  For the ease of use, a function
like lua_fixargs(L, nr_args, nr_upvals) would be nice.  (Even better
would be if Lua would know the nr of args and would do it automatically.)

But I bet, it's already too late for that.  Not that I didn't mention
this problem some months ago...

Ciao, ET.


PS:
> 4.0 API
>     // construction - given "stack" index
>     lua_ref
>     // tonumber method call
>     lua_getref
>     lua_tonumber
>     lua_pop
>     // destruction
      lua_unref
>     //    no API calls - trivial

Or you'll have a big memleak *g*