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

[bil til <biltil52@...>]

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...