Re: Packaging and importing

[Wim Couwenberg <w.couwenberg@...>]

Thanks for you feedback Diego!

> The way I do it is to have the Lua script load the C module and add to
> it all the sugar that it chooses too. In the next distribution of
> LuaSocket, I have socket/core.dll and socket/socket.lua. Require"socket"
> invokes socket/socket.lua, which requires socket.core and then adds
> stuff to it. Both invoke module("socket") so that goodies end up in the
> main namespace.

Yes, it can be done like this, but like I said, I don't view the Lua
script part as a separate module (or the DLL if you reverse the roles
of DLL and script).  The script is really private to the DLL and both
communicate through private functions and tables that are unreachable
from outside of the module.

> It is not worth it to worry about paths. I would suggest you simply use
> the engine provided by require itself.

I wouldn't have to worry if require simply passed the path as an
argument.  :-)  Look at it as a win-win situation since both your
approach and mine could be implemented easily.  Moreover, the changes
it would take to loader_C (or require) are minimal.

> All you have to do is return _M in the end of your module definition (as
> I added above). In C, you only have to return 1 from your loader, because
> luaL_module already leaves the namespace table on the stack.

Don't you agree that it would be much nicer if we only need to use
"module" and not rely on return values?  Then it is simple: "module"
determines the package table, period.  If a) modules are not placed
in the globals automatically and b) return values of packages are
ignored, there'd be no way around using "module" to properly setup a
package.

> In fact, inverting the order, in the case you choose to implement your
> modules by simply filling up a table and returning it, would still not
> work.

But that is exactly what I *don't* want to do.  I think the "module"
approach is nice and easy.  (If only it would would bind to the
required name instead of the module name.  Again, the changes to
"module" and "require" to support this binding are minimal.)  Here's
another example of possibly weird behaviour.  Suppose we implement two
packages "a" and "b" both adding to module "a", but without "b"
requiring "a".  Then

    local b = require "b"
    local a = require "a"

doesn't load package "a", while

    local a = require "a"
    local b = require "b"

does.  With a modified module function, both would work as expected.
Or should we compose a list of additional coding rules like

-  When in doubt, end your package with "return _M"
-  Before doing "module(name)" where <name> is not the package name,
you should also do "require(name)"

> Thanks for your comments! How did I go?

You try very hard!  ;-)  Seriously though, I think my small
wish list does not conflict with the spirit of the require proposal
(and would take only minimal changes):

1)  "module" binds to the "require"-ed name, not to the module name.

2)  Pass the resolved package path to the entry point (either in
loader_C or in some more general fasion in require).

And this one got added in the process:

3)  Drop the support for package return values, they're just confusing

Like I said, for deploying our own applications there is plenty of
room for solutions.  It is when developing a general purpose package
that such matters bug me...

--
Wim