4 ms·

Ha ha. You're describing the state of affairs before Underscore existed, back when functional-ish programming in JavaScript was ruled by Prototype.js: http://

Ha ha. You're describing the state of affairs before Underscore existed, back when functional-ish programming in JavaScript was ruled by Prototype.js: http://prototypejs.org/ http://prototypejs.org/ ... which added a lot of useful methods to native prototypes. While handy in controlled and limited environments, mucking about with native prototypes quickly becomes extremely dangerous and difficult — once you have two third-party modules on the page that expect different versions of your patched prototype method ... once you have a new version of a browser that implements one of your previously-extended functions, but does it differently — you're pretty well screwed. Both of those things tended to happen in large sites.

hamburglar 13y ago
Whereas with _.map, you always know exactly which implementation you're getting, right? :)
- jashkenas 13y ago
  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

Whereas with _.map, you always know exactly which implementation you're getting, right? :)

jashkenas 13y ago
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.