Why did luaL_openlib/luaL_register go?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Why did luaL_openlib/luaL_register go?

Are Leistad
This post was updated on .
Hi!

I just tried compiling some old Lua libraries. I understand that luaL_openlib has been deprecated for a while, and that luaL_newlib is now the preferred quick method for registering libraries. I've got my old libraries to compile using LUA_COMPAT_MODULE, so I'm good.

However, I haven't found out why luaL_openlib and luaL_register is out of the API now. These functions let us register a set of library functions with a prefix in a simple way, conveniently giving the "mylibprefix.myfunc" syntax. I've spent some time searching and browsing, trying to find out why they were deprecated and how to achieve the same result now, but nothing obvious has popped up yet. Thus I have some questions:
 
- why is are these functions now gone?
- is there a simple way to register a library with the "mylibprefix.myfunc" syntax, i.e. something equivalent of luaL_register?
- are there any reasons to avoid LUA_COMPAT_MODULE?

I've may very well have missed the obvious here...

TIA!

Are
--
Reply | Threaded
Open this post in threaded view
|

Re: Why did luaL_openlib/luaL_register go?

Rob Hoelz-2
On Tue, 7 May 2013 17:41:27 -0700 (PDT)
Are Leistad <[hidden email]> wrote:

> Hi!
>
> I'm just tried compiling some ols Lua libraries. I understand that
> luaL_openlib has been deprecated for a while, and that luaL_newlib is
> now the preferred quick method for registering libraries. I've got my
> old libraries to compile using LUA_COMPAT_MODULE, so I'm good.
>
> However, I haven't found out why luaL_openlib and luaL_register is
> out of the API now. These functions let us register a set of library
> functions with a prefix in a simple way, conveniently giving the
> "mylibprefix.myfunc" syntax. I've spent some time searching and
> browsing, trying to find out why they were deprecated and how to
> achieve the same result now, but nothing obvious has popped up yet.
> Thus I have some questions:
> - why is are these functions now gone?
> - is there a simple way to register a library with the
> "mylibprefix.myfunc" syntax, i.e. something equivalent of
> luaL_register?
> - are there any reasons to avoid LUA_COMPAT_MODULE?
>
> I've may very well have missed the obvious here...
>
> TIA!
>
> Are
> --
>
>
>
> --
> View this message in context:
> http://lua.2524044.n2.nabble.com/Why-did-luaL-openlib-luaL-register-go-tp7649023.html
> Sent from the Lua-l mailing list archive at Nabble.com.
>
luaL_register is gone because it encouraged developers to place their
libraries in the global namespace, which tends to be a bad idea.
module() was removed for the same reasons. The convention that Lua
library developers are moving towards is to return the library table
from the routine, so you may assign it to a variable in the calling
environment.  For example:

    /* in C land */
    int luaopen_mylib(lua_State *L)
    {
       lua_newtable(L);
       /* load it up with stuff */
       return 1;
    }

    -- in Lua land
    local mylib = require 'mylib'
    mylib.hello()

-Rob

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why did luaL_openlib/luaL_register go?

Are Leistad
I see - Thank you, Rob!

I shall go with the flow for new projects. Oh, and sorry for the typos, I was knackered, after many hours of Lua'ing. It was too much fun to sleep...

Are
--
Reply | Threaded
Open this post in threaded view
|

Re: Why did luaL_openlib/luaL_register go?

steve donovan
On Wed, May 8, 2013 at 11:55 AM, Are Leistad <[hidden email]> wrote:
I shall go with the flow for new projects. Oh, and sorry for the typos, I
was knackered, after many hours of Lua'ing. It was too much fun to sleep...
 
Oh we all know that!  I wouldn't worry that much about module(), it isn't intrinsically evil (but using package.seeall will not gain you friends among those who want to use your code in a sandbox!)

Most of the differences between 5.1 and 5.2 are made easier by the fact that 5.2 is usually compiled with LUA_COMPAT_ALL.  So these things are already defined:

#define lua_strlen(L,i)        lua_rawlen(L, (i))
#define lua_objlen(L,i)        lua_rawlen(L, (i))
#define lua_equal(L,idx1,idx2)        lua_compare(L,(idx1),(idx2),LUA_OPEQ)
#define lua_lessthan(L,idx1,idx2)    lua_compare(L,(idx1),(idx2),LUA_OPLT)

So (unless you make use of function environments) mostly it boils down to the module entry point, and the difference can be easily #ifdefed:

EXPORT int luaopen_mylib (lua_State *L) {
#if LUA_VERSION_NUM > 501
    lua_newtable(L);
    luaL_setfuncs (L,mylib_funs,0);
    lua_pushvalue(L,-1);        // pluck these lines out if they offend you
    lua_setglobal(L,"mylib"); // for they clobber the Holy _G
#else
    luaL_register(L,"mylib",mylib_funs);
#endif
    return 1;
}

Another issue that a porter will find with historical code is that it may contain Lua 5.0-isms that have finally been end-of-lifed.

For instance, luaL_reg is now spelt luaL_Reg, for both 5.1/5.2.  Some of the buffer macros likewise.

steve d.




Reply | Threaded
Open this post in threaded view
|

Re: Why did luaL_openlib/luaL_register go?

steve donovan
On Wed, May 8, 2013 at 1:04 PM, steve donovan <[hidden email]> wrote:
Most of the differences between 5.1 and 5.2 are made easier by the fact that 5.2 is usually compiled with LUA_COMPAT_ALL.  So these things are already defined:

Which means (to anticipate the obvious) that you have to define LUA_COMPAT_ALL in your code or build.

Authoritative list of differences is here:

http://www.lua.org/manual/5.2/manual.html#8.3

Note that lua_cpcall is also defined as a macro with LUA_COMPAT_ALL. The absence of luaL_typerror can be a bitch, however, and watch out for lua_load and lua_resume's extra parameter...

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Why did luaL_openlib/luaL_register go?

Are Leistad
steve donovan wrote
On Wed, May 8, 2013 at 11:55 AM, Are Leistad <aleistad@telia.com> wrote:

> I shall go with the flow for new projects. Oh, and sorry for the typos, I
> was knackered, after many hours of Lua'ing. It was too much fun to
> sleep...
>

Oh we all know that!  I wouldn't worry that much about module(), it isn't
intrinsically evil (but using package.seeall will not gain you friends
among those who want to use your code in a sandbox!)

Most of the differences between 5.1 and 5.2 are made easier by the fact
that 5.2 is usually compiled with LUA_COMPAT_ALL.  So these things are
already defined:

#define lua_strlen(L,i)        lua_rawlen(L, (i))
#define lua_objlen(L,i)        lua_rawlen(L, (i))
#define lua_equal(L,idx1,idx2)        lua_compare(L,(idx1),(idx2),LUA_OPEQ)
#define lua_lessthan(L,idx1,idx2)    lua_compare(L,(idx1),(idx2),LUA_OPLT)

So (unless you make use of function environments) mostly it boils down to
the module entry point, and the difference can be easily #ifdefed:

EXPORT int luaopen_mylib (lua_State *L) {
#if LUA_VERSION_NUM > 501
    lua_newtable(L);
    luaL_setfuncs (L,mylib_funs,0);
    lua_pushvalue(L,-1);        // pluck these lines out if they offend you
    lua_setglobal(L,"mylib"); // for they clobber the Holy _G
#else
    luaL_register(L,"mylib",mylib_funs);
#endif
    return 1;
}

Another issue that a porter will find with historical code is that it may
contain Lua 5.0-isms that have finally been end-of-lifed.

For instance, luaL_reg is now spelt luaL_Reg, for both 5.1/5.2.  Some of
the buffer macros likewise.

steve d.
Thank you , Steve!

I'm beginning to get acclimatized to "the new ways" now that I've gotten a few tastes of it. I can certainly see the point in leaving _G alone.

Which means (to anticipate the obvious) that you have to define LUA_COMPAT_ALL in your code or build.

Authoritative list of differences is here:
 
http://www.lua.org/manual/5.2/manual.html#8.3

Note that lua_cpcall is also defined as a macro with LUA_COMPAT_ALL. The absence of luaL_typerror can be a bitch, however, and watch out for lua_load and lua_resume's extra parameter...
 
Luckily, LUA_COMPAT_ALL saved me in this instance. I see that luaL_openlib isn't mentioned in the 5.2 changes, so it's clear I've been away for too long :-)

Are
--