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

Bill Keese bill at dojotoolkit.org
Sun Oct 10 19:22:39 EDT 2010


  I thought James picked require() because it makes sense for people 
using modules (as opposed to defining them), for example:

require(["dijit.Menu", "dijit.MenuItem"], function(Menu, MenuItem){
     var m = new Menu();
     m.addChild(new MenuItem());
     ...
});

I agree that "define" is more intuitive for defining modules, like:

define("dijit.Menu", [...], function(...){
     return dojo.declare(...);
})

On 10/11/10 7:06 AM, Kris Zyp wrote:
>   (Added dojo-contributors as cc since it affects current module
> refactor, response inline)
>
> On 10/9/2010 10:31 PM, James Burke wrote:
>> >  On Sat, Oct 9, 2010 at 11:56 AM, Kris Zyp<kriszyp at gmail.com>  <mailto:kriszyp at gmail.com>  wrote:
>>> >>  On 10/9/2010 12:49 PM, Kris Kowal wrote:
>>>> >>>  "ensure" is useful in both contexts.  "define" should
>>>> >>>  not be available in Module context because it does not make sense to
>>>> >>>  have a cycle in the layers of the architecture.
>>> >>  True, that's good point. So could we have a define.ensure for scripts
>>> >>  that are outside a CommonJS free variable context, but have
>>> >>  require.ensure that can be accessed from the require free variable
>>> >>  inside a CommonJS context (inside a define factory or commonjs module),
>>> >>  both aliasing the same behavior? That would seem reasonable to me.
>> >  I am hesitant to make another global in<script>  space for define.
>> >  <script>  space is even more sensitive to globals than the usual places
>> >  CommonJS modules are run, since all the scripts loaded via<script>
>> >  share a global space. I prefer the global impact for<script>  to be
>> >  very small. Right now, it is just "require".
>> >
> I am not suggesting adding "define" to "require", I am suggesting
> replacing/removing "require" with "define". There would still only be
> one global defined. There's no reason we ever had "require" as a global,
> and it is time to choose an appropriate global.
>
> Of course, I understand that RequireJS can't eliminate "require", since
> it is a core API for it. However, needing to have two globals is hardly
> going to get much sympathy from me, especially considering that the
> whole module system eliminates the need for developers to be fighting
> for globals at all. Back in the ol' days when we used archaic namespaces
> hung off globals this was a bigger issue. Now we could have dozens of
> globals without impacting the module system. EcmaScript itself defines
> dozens and the typical browser environment has hundreds of globals. Plus
> globals used without any community coordination (libraries grabbing
> common names as globals without namespacing) is the biggest source of
> possible conflict, but this is completely the opposite, it is totally
> being done as a community, and is exactly the**right**  way to establish
> globals. One or two (community ascribed) globals should hardly be a concern.
>> >  I also do not think define.ensure makes sense -- it really means a
>> >  kind of "require" vs a "define" -- the script requires that these
>> >  other scripts/modules are available before running the function.
> Its no less logical than require.def, whose purpose is to define a
> module. This is all about frequency. If every single module using the
> module definition API, but only a call or two that does the initial
> require (require([]) or define.ensure()), it makes sense to give the
> more frequently used form the most elegant logical API. Or we could have
> a "define" and have a global "require" like RequireJS's.
>
> But RequireJS doesn't even implement require.ensure, does it? It doesn't
> seem like this would affect RequireJS.
>
>> >  require.def vs require.define: what Kris Zyp said, and it just less
>> >  typing, which is nice for something that will be hand-written. I
>> >  consider it like var or fs, although I understand the "use real words"
>> >  approach this group has tried to follow. Originally I was happy with
>> >  just:
>> >
>> >  require('optional module ID', [dependencies], function (){ definition
>> >  function }).
>> >
>> >  Which would also work for an ensure-like behavior as well as handling
>> >  async module definitions, with the require('string only') form being
>> >  the traditional require. I appreciate that it may be seen as too much
>> >  to do as part of one function signature.
>> >
>> >  If it made a**strong**  difference to actual sync module proposal
>> >  implementors or people seriously considering implementation, then I
>> >  could put in an alias for require.define to require.def, but I will
>> >  likely still support require.def due to deployed code/existing users.
> I think the main reason this is worth considering is that it affects
> **every single**  module (and the byte count thereof, which quickly adds up
> for apps with many modules), so it is worth taking a hard look at what
> is best here even if there might mean some API change pain.
>
> -- Thanks, Kris
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20101011/9269ac9d/attachment.htm 


More information about the dojo-contributors mailing list