Re: [ANNOUNCE] Lua 4.0 (beta) now available

[Roberto Ierusalimschy <roberto@...>]

> 4) In 3.2 a global could be referenced with lua_Object - Now with the
> globals as a table there is no easy way to keep "pointers" to global
> variables :-(
> 
> 5) I have many functions that either creates tables or uses tables as
> parameters. .. All the recursive looping needs to be change since I cant
> pass lua_Object as a parameter anymore ...

You can use the stack position of your global in the place of a lua_Object.
Something like

   lua_getglobal(L, gname);
   gref = lua_gettop(L);
   foo(L, gref);

  void foo (lua_State *L, int gref) {
    ...
    if (lua_isnumber(L, gref)) ...  /* test whether global value is a number */
    ...
    lua_pushvalue(L, gref);  /* copy global value to stack top */
    ...

Usually, you can keep the strucutre of your code similar to the old version
with this approach. You can even define macros like

  #define luaold_getglobal(gname)	(lua_getglobal(L, gname), lua_gettop(L))

and redefine lua_Object to int. (This is not "equivalent" to the old API, 
because luaold_getglobal keeps its value at the top of the stack, so if you 
call it while buildind arguments or returns, you dirty your "C2lua" stack. 
For a more exact simulation, you sould use lua_insert to put the global 
value in an appropriate place inside the stack.) 



> 6) the luaL_check_string (lauxlib.h) is now const char* (used to be just
> char*) - const is correct - I know - but it break a lot of code (from a
> warning perspective)

You can either define const to nothing (a quick-and-dirty solution), or
redefine luaL_check_string to do the cast for you.


> 7) lua_open requires a stack size .... Default is 1000 - can this be changed
> while a state is open ?

No; the stack is fixed after the creation of the state (there are lots of
places that keep pointers to the stack inside the code).


> Conclusion #1 - Converting a big application based on Lua to 4.0 is non
> triviel and a fair amount of resources should be assigned to the task ..

That depends a lot of how complex is your use of the API. In fact, for
libraries that do not call back Lua (that is, where registered functions
do not use lua_call, lua_dostring, lua_dofile, etc.) we think that it
should be possible to write a compatibility module from Lua 3.2 to
Lua 4.0.

-- Roberto