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

Rawld Gill rcgill at earthlink.net
Thu Oct 14 05:35:36 EDT 2010

I just finished reading the commonJS thread completely, and I'll hang my
input here.

I prefer the choice of having the loader own the global "require". I like
the idea of commonJS owning the global "define". I prefer two variables
because I think the purpose of require is to define a loader and the purpose
of define is to define a module and these things seem independent.

The dependency vector seems much superior to searching code for require
applications. To me, is also seems superior to writing x=
require("myModule"). I frankly don't understand the resistance other than
"we already started doing it another way". Magical things are often more
complex; complex is bad. An API should be minimal, orthogonal, and
parsimonious. Multiple ways to do things breaks all three of these

And, searching the code won't solve the problem when the required modules
are calculated. But, I understand searching to be optional and deps can
still be specified.

Writing names out (e.g., "define" vs "def") is fine to a point. My
experience is dogma (e.g., we MUST always write every name out in full) is
bad and those who preach it usually don't have enough experience to
understand there are exceptions to almost every rule. In the end it is a
matter of taste and conceptual integrity of the interface. My taste would be
for "define" (if a global variable is being used) or "require.def" (if it is
being hung off of require).

Kris's idea about the define API (optional id, optional deps, implied
arguments based on number of args of factory) seems quite powerful. If we
must have all these options, this seems to be a good approach.


> -----Original Message-----
> From: dojo-contributors-bounces at mail.dojotoolkit.org [mailto:dojo-
> contributors-bounces at mail.dojotoolkit.org] On Behalf Of James Burke
> Sent: Tuesday, October 12, 2010 6:25 PM
> To: dojo dev.; commonjs at googlegroups.com
> Subject: Re: [dojo-contributors] Asynchronous Module Definition (was Re:
> [CommonJS] Another idea on unifying Transport/C and /D)
> On Tue, Oct 12, 2010 at 2:36 PM, Kris Zyp <kzyp at dojotoolkit.org> wrote:
> > If you care about reducing naming hazards (which is the whole purpose
> > of minimizing globals), it seems like the best options would be for
> > CommonJS to keep "require" and RequireJS to use "requirejs", or
> > CommonJS could use "define" and RequireJS could keep "require".
> > Sharing naming authority of "require" isn't really a tenable option for
> naming safety.
> I care about reducing hazards to existing code in the wild. My potentially
> poor choice of how I implemented require seems to be orthogonal to that
> point. Existing code in the wild could have a define or require that are
> likely *not* CommonJS-compatible, and having two globals that could
> potentially conflict with existing code is more troublesome than one. As
> mentioned, that point is not a complete reason for killing the proposal,
but it
> is tradeoff with the proposal.
> And to be clear, I think there will be two globals, because to allow
> the "ensure" or some bootstrap method (whatever the name) should be
> specified, and that seems unlikely/unnatural to be off of define.
> James
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5525 (20101012) __________
> The message was checked by ESET NOD32 Antivirus.
> http://www.eset.com

More information about the dojo-contributors mailing list