Re: changes in 'require'

[David Burgess <dburgess@...>]

1) Lua modules before C.
I think this is retrograde step. The argument that Lua should be first
because "it is more flexible" is fallacious. The argument couldd also be
that it makes a package installation more easily corrupted. We have
been using different versions of require for over a year now and we find 
the C before Lua protocol to work rather well. This change is also
rather disruptive, we have got used to the the way it searches and
find it convenient.

2) Search path. Am I to understand that the meaning of also using the
"C search path" means that you intend to search the %PATH% or do you
mean package.cpath? Extending the number of places to search comes at
a price. I have carefully measured the timings of the existing
search stratgeies on two platforms and the overhead is minimal. It
would be nice to keep it this way. (The final downside to this is
that I will need to repeat the performance measurements).

3) There seems to be an assumption that require will only be used
on systems with hiearchical file systems. There are three flat world
environments that I use. I trust that the current resstructuring will 
take into account flat filing systems.

4) My specific point of interest is embedding Lua code inside Win32
DLLs as resources. We implement this by populating preload with
lazy initialization functions. e.g.

  preloadfnc()
    load the resource()
    execute the resource
  end

The ONLY problem that we have had with work6 require is the question
of how to boot these preloads? This, as I read it, was Diego's original
question. An external Lua script (like init.lua) defeats the original aim
of loading the lua code from DLLs. Adding a resource loader to the
loader chain is problematic because it is application wide it impacts
all packages not just those that are resource loaded.

regards
David Burgess