Modules: Name capture
ihab.awad at gmail.com
ihab.awad at gmail.com
Tue Jun 1 17:23:51 PDT 2010
On Thu, May 27, 2010 at 6:57 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Last I checked, CommonJS (ignoring packages, which NodeJS and others are
> avoiding) uses implicit linking via the filesystem.
CommonJS is right now working on much the same issues: what does it mean for
two modules to be the "same"? There is an active discussion, and a variety
of implemented and in-process specs including:
The common desire is to be able to grant a package (of modules) autonomy
regarding what it depends upon. This is by no means a filesystem-only
approach, and the "implicit"-ness of the linking is debatable given that it
is driven by pretty extensive metadata.
Now, a bit of background. In CommonJS, the expression:
means, "find the module 'foo/bar/baz' in whatever package mappings may
exist; instantiate a singleton in the current sandbox; and return the
singleton". A CommonJS sandbox is equivalent to Sam and Dave's "loader".
With that in mind, NodeJS does not, at this point, implement an API for
building a new sandbox/loader:
This means that the singleton of 'foo/bar/baz' is a singleton in an entire
OS process. They are doing just what Python has done for a long time, based
on filesystems, and are *not* trying to deal with the problem of multiple
loaders connected by object references.
This is extremely common -- see Python and many other languages.
Yes, and Python and these other languages pull modules out of a centrally
curated PATH of some sort wherein 'foo/bar/baz' has an unambiguous meaning
to all other modules "installed" on the "system". We are tasked with
creating a module system for a world in which these initial conditions do
It is so convenient than any explicit-linking system delivered in an Ecma
> de-jure standard will beget implicit linking systems built on top (like
> CommonJS's) in the wild, imposing costs that we could head off by
> standardizing implicit linking. Which simple modules proposes.
At this point, it's not clear where CommonJS is going to end up after
navel-gazing over the problem of distributed module management. It is clear
that they have not arrived at the current "simple modules" design. _Pace_
the definition of implicit vs. explicit linking, I think the problem
deserves some further thought. I'm on the hook to provide a clear
restatement of my Solution 2 (which, I repeat, may not solve the problem but
will I hope clarify some issues), and I have every intention of delivering.
Ihab A.B. Awad, Palo Alto, CA
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss