4 ms·

Actually, you do. You've loaded it, and you can lock it down privately to your library or app with _.noConflict(). You can have ten different versions of Under

Actually, you do. You've loaded it, and you can lock it down privately to your library or app with _.noConflict(). You can have ten different versions of Underscore loaded on the page, living in peace and harmony, in ten different third-party modules. Not that you should. But that you could.

hamburglar 13y ago
Well then I guess this _ has a bug because it doesn't have a 'noConflict' method. :) But to be perfectly fair, you are 100% correct: this is not a technical complaint and perhaps this entire sub-thread is, as has been claimed, "bike-shedding." Since this lib is designed to be loaded via an AMD-style mechanism, users can call it whatever they want, so _ is just as valid an identifier as any other. Except the obvious issue that readers of the code, examples, and any code that follows suit, will end up with this completely pointless ambiguity because _ is ultimately a meaningless name if it evolves to mean simply "some library I loaded." You may as well write sample code like: var $ = require('http'); $.createServer(...); I would think people would call that out as ridiculous and confusing.
jdd 13y ago
Extending native prototypes creates other less obvious hurdles for libraries too. Craft.js, es5-shim, Modernizr, MooTools, Prototype.js, and Sugar.js, to name a few, have all, at one time or another, added incorrect shims to native prototypes. While Underscore is in a better position than those that extend native prototypes, regarding api/environment conflicts, it can still be tripped up by poor shims because it defers to many ES5 methods if they exist. For example, if Prototype 1.6.0 and Underscore.js are included on a page Underscore's `_.reduce` method won't work properly. This is one of the reasons why libs/frameworks like Dojo, Ember, Lo-Dash, RequireJS, Sizzle, and YUI do native checks too.

hamburglar 13y ago

Well then I guess this _ has a bug because it doesn't have a 'noConflict' method. :) But to be perfectly fair, you are 100% correct: this is not a technical complaint and perhaps this entire sub-thread is, as has been claimed, "bike-shedding." Since this lib is designed to be loaded via an AMD-style mechanism, users can call it whatever they want, so _ is just as valid an identifier as any other. Except the obvious issue that readers of the code, examples, and any code that follows suit, will end up with this completely pointless ambiguity because _ is ultimately a meaningless name if it evolves to mean simply "some library I loaded." You may as well write sample code like: var $ = require('http'); $.createServer(...); I would think people would call that out as ridiculous and confusing.

jdd 13y ago

Extending native prototypes creates other less obvious hurdles for libraries too. Craft.js, es5-shim, Modernizr, MooTools, Prototype.js, and Sugar.js, to name a few, have all, at one time or another, added incorrect shims to native prototypes. While Underscore is in a better position than those that extend native prototypes, regarding api/environment conflicts, it can still be tripped up by poor shims because it defers to many ES5 methods if they exist. For example, if Prototype 1.6.0 and Underscore.js are included on a page Underscore's `_.reduce` method won't work properly. This is one of the reasons why libs/frameworks like Dojo, Ember, Lo-Dash, RequireJS, Sizzle, and YUI do native checks too.