Re: Meta function tables for LUA_FILEHANDLE: why two separate tables?

[bil til <biltil52@...>]

PS: Sorry, this luaL_newmetatablex would need to defined as macro, I
just recognized (my compiler gives warnings due to sizeof usage... the
problem is, that lua_newlibtable is defined as macro with sizeof
usage...), e. g. like this:

#define luaL_newmetatablex (l, name, l__, l, nup)                         \
do{
                              \
  luaL_newmetatable(L, name);
           \
  luaL_setfuncs(L, l__, 0);
                  \
  luaL_newlibtable(L, l);
                   \
  luaL_setfuncs(L, l, nup);
                 \
  lua_setfield(L, -2, "__index");
               \
  lua_pop(L, 1);
                     \
} while(0)

Am So., 20. Nov. 2022 um 06:40 Uhr schrieb bil til <biltil52@gmail.com>:
>
> Am Fr., 18. Nov. 2022 um 20:54 Uhr schrieb Marcus Mason <m4gicks@gmail.com>:
> > I think that metatables being open to extension is fine if you namespace the keys (for example __module_mycustomkey or whatever). It enables a kind of ad-hoc polymorphism for user defined functions which I quite like. I think with some cleverness around __metatable one could protect themselves from clobbering of built in keys and still have this functionality too.
> >
>
> Yes I think this sounds reasonable, so the Lua programmers somehow can
> decide what they want... .
>
> Just I think it would be nice to implement a special luaL_... function
> for this "safe create meta" approach, e. g. programmed like the
> following (similar to createmeta function in liolib.c:
>
> static void luaL_newmetatablex (lua_State *L, const char* name, const
> luaL_Reg l__[], const luaL_Rhchar l, int nup ) {
>   luaL_newmetatable(L, name);  /* metatable for file handles */
>   luaL_setfuncs(L, l__, 0);  /* add metamethods to new metatable */
>   luaL_newlibtable(L, l);  /* create method table */
>   luaL_setfuncs(L, l, nup);  /* add file methods to method table */
>   lua_setfield(L, -2, "__index");  /* metatable.__index = method table */
>   lua_pop(L, 1);  /* pop metatable */
> }
>
> ... creating such a new luaL... function does not pinch anybody, as
> any good compiler/linker anyway will skip such a function if it is not
> used... (the C code of Lua generally is really super clearly
> structured... it should be no problem for any better compiler/linker
> to check this structure).
>
> ... btw, it would be very nice if there would be some deeper short
> comment about this in PiL book, chapter 31, "Object-Oriented Access"
> ... even in Version 4 here the code shown of this chapter seems to
> have been modified since 2003, at least in the book I have at home it
> seems to be different than in the 2003 (V4) PDF, which I find on my
> PC...