Re: changes in 'require'

[Edgar Toernig <froese@...>]

Diego Nehab wrote:
>
> You would have file
> 
>      /lib/foo/meta.dll
> 
> If require "foo.bar" fails, we would try loading "foo.meta" and then
> retry "foo.bar", and then "meta" and retry "foo.bar". (I.e., we look for
> meta packages backward in the chain, until we find one tha satisfies our
> dependency).

> The advantages are many. There is no more implicit call to require"foo"
> itself. Additional work is only done on failure. Meta.dll knows it can only
> be called implicitly, so it doesn't have to be told so. We now can 
> override a virtual subpackage by simply creating a real file for it.

How's that going to work?

Someone wants to patch i.e. foo.bar - he creates a lib/foo/bar.lua which
calls require"foo.meta" first and then patches around.

At first it looks like your solutions works very well.  require"foo.bar"
loads "foo/bar.lua", which loads "foo/meta.dll".  It may be a little bit
ugly/strange that meta.dll modifies the loaded-table of require for bar.lua
while bar.lua it is still running but anyway, let's ignore that for the
moment.

What happens if a user of the package calls require"foo" (or "foo.baz") first
and only later "foo.bar"?  Then bar.lua is never executed!

IMHO, every identifier passed to require should have an accompanying file
in the filesystem.  These may only be simple stubs containing nothing but
a single 'require"foo.meta"'.  If you want all of them bundled in a single
file add tar/jar/zip support to lua.

Ciao, ET.