Modules: Name capture

ihab.awad at gmail.com ihab.awad at gmail.com
Tue Jun 1 17:23:51 PDT 2010


Hi Brendan,

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:

  http://wiki.commonjs.org/wiki/Packages/Mappings/B

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:

  require('foo/bar/baz')

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:

  http://nodejs.org/api.html

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
not apply.

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

-- 
Ihab A.B. Awad, Palo Alto, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100601/f4c3dedf/attachment.html>


More information about the es-discuss mailing list