lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

>>>>> "Milan" == Milan Obuch <> writes:

 Milan> Also, additional question - following definition

 Milan> #define ARRAY_REGID  "22d3fa81-aef3-4335-be43-6ff037daf78e"

 Milan> used later in

 Milan> luaL_newmetatable(L, ARRAY_REGID);

See, this is why I don't like luaL_newmetatable / luaL_checkudata. (I
prefer to use userdata keys rather than string keys where uniqueness

 Milan> Looking in Reference Manual, second argument is just char
 Milan> pointer, so I could basically use any name, it does not need to
 Milan> be such special string as used in cited example, right? Even
 Milan> meaningfull ones as 'dog', 'cat' etc. yes?

It can be anything that does not collide with any value that some other
module might use. Since you don't know what other modules might use, you
have to guess; in this case the author obviously decided that a UUID
would be the safest bet.

 Milan> Also, there is mention of a registry, where new metatable is
 Milan> being put, but I did not find any definition of this registry.
 Milan> Maybe I did not look into the right place, but where could
 Milan> definition of registry be found?

The registry is a Lua table associated with the lua state that holds
data that is of interest at the C level but which shouldn't normally be
exposed to Lua code. You can get at it from Lua only with
debug.getregistry(), but C code can access it at any time using the

Typical stuff in the registry is:

  - the original global table reference

  - the thread object for the main thread

  - metatables for built-in objects such as LUA_FILEHANDLE, and also
    for any objects that use luaL_newmetatable / luaL_checkudata

  - references created with luaL_ref

  - the _LOADED table, which is also visible by default at
    package.loaded, but it's the registry reference which is actually

  - a table of dynamically loaded objects, on platforms that support

  - anything that any C module decided to put there (which can often
    be quite extensive)