[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Module system curiosity
- From: Mark Hamburg <mark@...>
- Date: Sun, 30 May 2010 11:42:44 -0700
On May 30, 2010, at 11:31 AM, Florian Weimer wrote:
> * Mark Hamburg:
>> The simple fix is to change the module function so that it doesn't
>> set any globals but rather just populates a registry of loaded
>> modules. That way, in your example, all that require "lpeg" would do
> What would you suggest for nested modules? Return the top-most module
> along the path? But that might contain other non-imported modules.
I'll admit I've never been a fan of nested modules, but that may just be the Oberon bias showing through. But if one must have hierarchical modules, then from a registry standpoint 'require "foo.bar"' is really just the same as a non-hierarchical module named "foo.bar". If you want this accessible via the module foo, then you simply re-export "foo.bar" under the name "bar" when you build foo.
module( ... )
bar = require "foo.bar"
I would like a system that allowed for a top-level public module and private sub-modules that could only be imported by the top-level module -- i.e., I could do
module( ... )
local imp = require "imp"
And this would find an imp module somehow related to foo that would not be available for use outside of the load of foo (or outside of the code for foo as controlled by a custom version of require within foo).