Hi Brendan, On Thu, May 27, 2010 at 6:57 PM, Brendan Eich <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
