Re: changes in 'require'

[Diego Nehab <diego@...>]

Hi,

> I.e. require("socket") loads socket.lua and this in turn uses
> require("_socket") to load socket.so. I think the underscore makes
> it clear that this module is 'internal' and applications should not
> load it directly (I know Diego doesn't like this convention, but
> LuaSocket was the easiest example :-) ).

There you go... if I had listened to you, I wouldn't have the 'l'
problem I have now! :)

What I am currently using in my development version is a core.so, inside
the socket directory:

    lib/socket/core.so
    share/socket/init.lua

A call to require"socket" finds init.lua. This in turn calls
require"socket.core". According to the new scheme, there will be an
implicit, recursive, second call to require"socket".  Since require()
checks for recursion, this won't be a problem.

What is not possible to do is to load just the core, not the sugar
that init.lua adds to it. Under the new scheme, init.lua will *always*
be called.

If the implicit calls to require() could be identified by the modules
being loaded, on the other hand, init.lua could refrain from loading the
sugars if they had not been required explicitly. This is my last bid for
a
way to tell them appart.

> I think a convenient solution would be to strip an underscore prefix
> from the module name before generating the init function name.
> This way it's easy to move (say) foo.so to _foo.so and load it with
> require("_foo") from foo.lua.

I like this. This solves an entirely different problem and I have no
objections to the _ prefix in this case.

[]s,
Diego.