Re: Newbie questions on luaopen_, metatables, userdata (Chapter 28 in Programming in Lua (2nd ed.))

["M.C." <mailcoward@...>]

On Tue, Jun 3, 2008 at 4:20 AM, Etan Reisner
<deryni@unreliablesource.net> wrote:
> On Tue, Jun 03, 2008 at 02:02:11AM -0700, Mail Coward wrote:
>> Hello I have some newbie questions in the Programming in Lua Book (2nd ed).
>>
>> In Chapter 28 where a custom array type is made with userdata and
>> metatables, why isn't the stack 'balanced' in the luaopen_array? I thought
>> the stack should always balance back to what you started with at the
>> beginning of the function. In the 1st metatable example the stack is 1
>> larger than when it started. In the object example, the stack is 2 larger
>> than when it started. (The function still returns 1.  What does the return
>> value mean?)
>
> I haven't read PiL2 so I can't comment specifically

It looks very much like the PiL1 on the website except it is a
bitfield array example now instead of an array of doubles and the
luaL_openlib seems to now be luaL_register.

but balancing the
> stack is a strongly suggested recommendation so that you don't have stack
> sizing/memory growing issues later down the line. That being said when you
> call from lua into a C function lua takes care to 'zero' the stack before
> the call (so that your C function arguments are at the start of the stack)
> and after the call (so that any extra arguments/return values are popped).
> The return value from a lua C function is the number of arguments that the
> function is going to return to lua.
> (See http://www.lua.org/manual/5.1/manual.html#3.1 and the linked
> http://www.lua.org/manual/5.1/manual.html#lua_CFunction for explanation.)
>

So I am to think of this luaopen_array() function as something Lua
calls and when it returns, it resets the stack? When the function
first starts, lua_gettop() reports 1. The function returns 1. What is
the function returning back to Lua. And why don't I need to concern
myself with the fact that all those intermediate calls like
lua_newmetatable and lua_register continue to increase the stack size
but don't get returned, and Lua is going to effectively zero the
stack? I'm wondering how these values survive to do anything useful or
don't blow up the stack.



>> If I needed a second kind of array (or maybe a struct just to be a little
>> different) in this same library, which needed its own metatable, is it safe
>> to just creating new different metatables in the luaopen_ function? So does
>> this work and safe?
>>
>> int luaopen_array (lua_State *L) {
>>
>>   luaL_newmetatable(L, "LuaBook.array");
>>   lua_pushvalue(L, -1);
>>   lua_setfield(L, -2, "__index");
>>   luaL_register(L, NULL, arraylib_m_forarray);
>>
>>   luaL_newmetatable(L, "LuaBook.struct");
>>   lua_pushvalue(L, -1);
>>   lua_setfield(L, -2, "__index");
>>   luaL_register(L, NULL, arraylib_m_forstruct);
>>
>>   luaL_register(L, "array", arraylib_f);
>>   return 1;
>> }
>
> That looks fine to me, yes. Though I question why you would want to be
> initializing LuaBook.struct in the array opener and not in its own. Also,
> you do know that the code as written above will create metatables with the
> names "LuaBook.array" and "LuaBook.struct" and not a table with the name
> "LuaBook" with two keys in it ("array" and "struct"), correct?

I was thinking I might want to think of a library as a large piece of
functionality (like the math library). I was thinking a little bit
about window kits and they seem to have a bunch of types like size,
point, rect, etc. If I wanted to write a library like 'window', it
seemed like I would want all those separate data types together, yes?


>> I saw this in the 5.1 ref manual:
>>
>> "The luaopen_* functions (to open libraries) cannot be called directly, like
>> a regular C function. They must be called through Lua, like a Lua function."
>>
>> Why is this and how should I be opening this library from C?
>
> This is because some of them expect to be run from within an existing lua
> context and when called from C directly this will not be the case. The
> last paragraph of http://www.lua.org/manual/5.1/manual.html#5 explains two
> ways they can be called.
>
>> And must all my library open methods be named luaopen_*? Do things break if
>> I call it something else like init_mylib()?
>
> Yes, your library open methods need to be luaopen_* (or at least follow
> the rules described in
> http://www.lua.org/manual/5.1/manual.html#pdf-package.loaders). The names
> are necessary so that the default lua C module loader can find the entry
> point. If you wanted to write your own C module loader you can do that and
> then have it look up any symbol you wanted to.
>
>> Thank you
>
>        -Etan

Your answer has cleared up these two issues are now clear for me.

Thank you for your helpful answers.