Re: Update #4 to Lua 5.1-work3 loadlib cleanups

[David Burgess <dburgess@...>]

On Thu, 23 Dec 2004 11:20:34 -0200, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> Our main rule is "keep it simple"

I agree with the aim.
Roberto, has convinced me on almost every front. 
Forgive my persistent questioning of the Win32 loadlib implemenation.

Re: Win32
I can live without the upvalues and I can live without the trailing whitespace
removal.

I have two remaining issues with Win32 loadlib().

The loaded module handles are useful for a number of API calls. What about
adding another table to package that maintains the handles and keyed
by the file name e.g. pak. i.e. package.clib['filename'] = (HMODULE)libhabdle
This means they are accessible by C code and they do not have to be
reestablished.
The aim here is to reuse the module handle rather than having to resort to
issuing another LoadLibrary or GetModuleHandle() when I need the module handle.

The second issue is the pathnames for libraries. Methinks there is
no Win32 equivalent to /usr/local and having library names relative to the
loading module is simpler. (Path agnostic as Mike says). Fixed pathname
defaults can make life complicated in Win32. Moreover, everybody will
want to install Lua DLLs in different places and in different ways. 

Just to prove I cant count, the third thing I keep wondering about is the
the dotted names for require e.g. require 'socket.http' I think this is
just fine for Lua modules but the way I read the code for C modules
it means that:

require 'socket'  --calls luaopen_socket in socket.dll
require 'socket.http' - calls luaopen_sockethttp in DIRSEP derived dll 

The problem I see with this is that it is not easy (or possible) to put
luaopen_socket and luaopen_sockethttp in the same DLL. Is this so,
or have I missed something obvious? For Win32 this would seem
to be an unnecessary DLL breeder. Any ideas and how this might be 
done?