[dojo-contributors] Asynchronous Module Definition (was Re: [CommonJS] Another idea on unifying Transport/C and /D)

James Burke jrburke at gmail.com
Tue Oct 12 16:55:02 EDT 2010


On Tue, Oct 12, 2010 at 11:31 AM, Kris Zyp <kriszyp at gmail.com> wrote:
> Again, the suggestion is that CommonJS only define a single global not
> two.

This specific suggestion might be for just one, but for the loader to
actually be useful, it will need a bootstrap call require([]) or
require.ensure, so I still see it as needing two globals, since
hanging the bootstrap call off of define seems unlikely.

> In fact this should actually improve the conflict/pollution
> potential of RequireJS. If RequireJS uses a community global (require or
> define) and defines its own APIs on it, it is effectively polluting the
> global/shared namespace with possible name conflicts just as much as if
> it defines all its APIs directly on window. By putting modify(),
> version, plugin(), isBrowser, baseUrl, etc. on a shared object
> "require", you are injecting into a shared space. "require"'s can have
> conflicts just like "window". By claiming that you are not using globals
> because it is under require is a silly name game, it is still shared. If
> CommonJS only defines a global "define" than RequireJS can use a single
> namespace under require (since "require" would be free then) and keep
> its own API separate from the shared namespace. This is the right way to
> avoid conflicts (which is the point of avoiding global pollution,
> whether it be the "window" global or any other shared namespace).

Implementations of a spec usually provide some extensions. If you want
the code to be most portable do not use the extensions, like using
__dirname and __filename in node.

My main concern was with existing code that might have a non-compliant
globals that want to gradually upgrade to the new API. Having two vs
one possibly conflicting globals makes conflict more likely, but it is
not a reason on its own to discount considering a new global.

James


More information about the dojo-contributors mailing list