Re: changes in 'require'

[Diego Nehab <diego@...>]

Hi,

Let's sumarize the problem and for try a different approach.

Say you have package "foo", with submodules "bar" and "baz". How do you
deploy this package inside a single file (i.e., we want to make
"foo.bar" and "foo.baz" be *virtual* packages) Moreover, how do you do
it in such a way you don't have to explicitly tell the interpreter that
"foo" has these submodules inside it (i.e, zero configuration)?

Forcing require"foo.bar" to implictly generate a call to require"foo"
solves this problem.

It creates another problem, which is that require"foo.bar" will *always*
load "foo", even when "foo.bar" doesn't actually depend on it. This
could be too expensive (even if "foo" knows it's being called implicitly
and choose not to do anything, loading an extra library might already be
too expensive).

Now, the original problem only exists if require"foo.bar" fails
according to the current way of doing it. In theory, we only have to do
something different in that case.

How about fixing the name of any library that exports submodules to 
"composite.dll", "meta.dll", "bundled.dll", or something like that?

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.

[]s,
Diego.