Re: changes in 'require'

[David Burgess <dburgess@...>]

On reflection I should never have mentioned the require issue.
Work6 require suits me rather well with the exception of DLL
packaging and the flat file system issue, this can be solved by 
modifying the supplied packages and/or using lazy preloads.
The point is that I am starting to agree with Roberto's view that
work6 require be left alone. My reasons are:
1) I do not wish to give away any of the features or function in work6.
2) I like the current loader sequence. (e.g. preload, C, Lua)
3) I am familiar with work6 code and it presents an easy upgrade for
my existing Lua 5 code base.
4) Roberto's arguments have some impact.

My alternative solution is to adopt a convention for coding modules
that reads like :

local a = require("a")

< more code >

module("a.b")

This matches Diego's habit in the last luasocket issue. Most 
modules require their parent before they issue the module().
This means that I can achieve my flat filing system and resource
loading requirements by priming the preload of the parent of
the package without too much work and the ocassional 
modification of require() sequences in packages. 

Whilst this is a pain I think I would rather live with pain than see
the current Lua work6 require() messed up. work6 require is 
clean and tight. 

David Burgess

PS
In all the discussion I hope that two key points were not missed,
namely; removal of the getc() from lauxlib.c and the addition
of GetModuleFileName() substitution for Win32 in LUA_CPATH
(and maybe LUA_PATH).