Re: changes in 'require'

[David Burgess <dburgess@...>]

Just to be sure. I am presuming this is added to the current order
of preload, C loader, Lua Loader.

> - add another loader after the others:
> when requiring "a.b.c", it trys to find a module "a" in the C path;
> if found, tries to find the function luaopen_a_b_c there and returns it.
Does this mean that require"a.b" will also try module "a" in the C path;
if found, tries to find the function luaopen_a_b?

This means I could package a socket.dll with entry points of
luaopen_socket
luaopen_socket_http
luaopen_socket_smtp
etc
Yes? If this is true then we have A DLL with entry point for everything
that we wish load rather than priming the preload table. This is
fine.

Having just rerread loadlib.c win32 loader code may I suggest one small
enhancement which will help the above strategy.

If we were to assume that it is fair that the LoadLibrary need only be
tried once when it is unsuccessful, the handle to the library could be
initialized to (HANDLE)-1 so that NULL means failed to find it and 
(HANDLE)-1 means we have not tried it. This means that 
require"a.b.c.d"
require"a.b.c.e"
will only perform the LoadLibrary test on "a.dll" once in the life of the
registry.

> (I assume that there is no need to pack whole *submodules* as one DLL,
> so there is no need to look for a.b or anything like that.)
I do not understand what you mean.


> (Unlike the original C loader, it is not a hard error not to find the
> open function there. It is simply a soft error meaning "module not found
> here".)
I cant see how this would work when we have a usual case of a library like
require"a"  -- calls luaopen_a in library a
require"a.b" - -- expects "a/b.lua"

So "a/b.lua" happens to have been deleted which means that the second 
require will never fail.



> If we really want to care for the obsessive people:
> 
> - add yet another loader after the others:
No.
If this is the 5th loader, no. LoadLibrary() on Windows with a
LUA_CPATH of  "?.dll" would potentially search the the Windows path
each time (plus the Windows search strategy), this takes a looong
time. Adding this loader would be the third unsuccessful LoadLibrary()
call. This would take seconds.


David B