Re: Lazy loading of (sub)modules

[David Manura <dm.lua@...>]

On Mon, Dec 5, 2011 at 5:44 PM, KR <krunal.rao78@gmail.com> wrote:
> [...]
> but sometimes sub-modules contain too much code for a single lua file (IMHO and
> in my case). At the moment I am solving the issue by having the sub-module (xxx
> above) importing everything (z and much more) from a list of lua files to
> itself:
>
> -- xxx.lua:
> local _M = {}
> import(_M, require "mylib.xxx_imp.a") -- implementation not shown here.
> import(_M, require "mylib.xxx_imp.b") -- I could use dofile as well, xxx_imp not
> "exposed"
> ...
> return _M
>
> This requires me to manually edit the xxx.lua file every time some new
> functionality is added to xxx.

And what's wrong with doing that?  ;)

Please also note that those deploying your modules might not intend to
install them according to your preconceived file layout.  They might
compile them to bytecode, run bin2c [1], and/or use a bundling
approach like [2].  These would break if you relied on a module
loading technique like lfs.dir.

[1] http://lua-users.org/wiki/BinToCee
[2] http://loop.luaforge.net/release/preload.html