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

James Burke jrburke at gmail.com
Wed Oct 13 13:31:48 EDT 2010


On Wed, Oct 13, 2010 at 6:40 AM, Kris Zyp <kriszyp at gmail.com> wrote:
> require/require.* - Reserved for module loaders. A module loader is free
> to use this global variable as they see fit, and can add implementation
> specific properties/functions to this object or function (or not use it
> all). This global should only be used by CommonJS module loaders.

I would think require.ensure would be on the global and not the free
variable, otherwise I cannot see how to bootstrap the load, without
first calling define:

define(function(require){
   require.ensure();
});

which seems awkward. I can see some loading scenarios that would not
require a bootstrap call, but most browser-based ones will work better
with it, and if the goal is interop, it seems like that would be
specified in a spec/proposal, likely placing it on the global require.

I appreciate the desire to keep implementation and spec spaces clean,
but I think that could still be accomplished via what you proposed
earlier, specifically for RequireJS, to use a requirejs global for any
of its custom items and reserving require for just require() and
require.def() (although I am not necessarily agreeing to do that work
:). So I do not think the AMD proposal API is broken, maybe some
inadequacies in how I implemented in RequireJS, but the API is fine as
already specified.

To Fabian's point, I would not want to choose an API because of ease
of implementation in a specific engine, node could have very well
disallowed attaching anything to global. The way to fix node is to
provide a patch and lobby for it, although, sounds like it may work
out without too much lobbying.

James


More information about the dojo-contributors mailing list