Re: changes in 'require'

[Mike Pall <mikelu-0507@...>]

Hi,

Roberto Ierusalimschy wrote:
> > What is not possible to do is to load just the core, not the sugar
> > that init.lua adds to it. Under the new scheme, init.lua will *always*
> > be called.
> 
> On second thoughts, maybe this is a good argument not to load parent
> modules automatically.

I don't know what Diego doesn't want to load in the parent when
it's loaded only on behalf of a child (I've looked into the
LuaSocket betas and really have no clue).

Diego, please enlighten us ... maybe this can be solved with
some restructuring.

I think parent modules should be all-or-nothing style. Either they
load all the functionality needed for their children or nothing.
If they load functionality that is orthogonal to that needed for
their children (or likely users of their children) then this
functionality should be put into a submodule (or in a different
package).

You could even demand load the orthogonal functionality upon
first use. Easy enough: use __index on the module table or add
trampoline functions that load a function to replace itself
in the module table and then chain to the function. But really,
this is duplicating functionality that is better solved with
the (hierarchical) module system.

> (To ignore errors does not help here, and to make
> modules aware of why they are being called will only make things much
> more complex than they already are...)

Fully agree.

> Mike said this makes his life easier. Why?

BTW: David Burgess also said it solves a problem for him.

Because some common infrastructure from the parent module is needed
by all child modules. So every child has to load the parent anyway
(or duplicate the infrastructure setup). This is very annoying to do
in C modules, especially if you aim to be module-name agnostic.

Of course if children can just _assume_ their parents have been
loaded successfully (*), this makes many things easier and more
maintainable.

(*) Another good reason for fail-if-parent-is-not-there.

> Maybe we should go back to the original scheme and look for another
> solution to the single DLL problem?

I still think the hierarchical require() is the best solution for
this problem. And it solves other issues as well.

Bye,
     Mike