Put all variable declartions in a row, so they can all be
chained together with commas by compiler.
Move wrapper creation code down in OO section. Not necissary
for `var wrapper` to be defined when _ constructor is defined.
Preparing way to make OO wrapping optional..
This way we only get the native versions of functions we use.
Will make testing non-native versions as we can't just swap do `_.Native = {}`,
but this wouldn't have worked for `isArray` and `keys` anyways, as these are
looked up on initialization, so I think the solution is to have an init()
method on underscore where we will re-initialize functions and try and use
native versions then
You would use this to compile your code _with_ underscore, to
remove all those dead underscore functions you don't use.
Slight tweak to code to `root._` code to get working, and must
remove anonymous wrapper function for current closure compiler to
remove dead code.
Compare an object's function with === to the native
version before calling it. That is, don't just assume that
because an object has a 'filter' property thats a function,
that we should call that in _.filter().
Expose the native methods found as _.native
On the way towards being able to turn off native implementations,
though there are tradeoffs...
While I'm not a fan of making abstractions where a simpe solution
exists, I think this is good as it makes a public API for extending
underscore, therefore making it "ok" to make your own alias names.
Also give us some future proofing in case we ever add in hooks on
method definition. For example, right now if you add a method
or make an alias in user code, it isn't added to the wrapper prototype.
Added tests and inline docs, no external docs
Even though the native methods have worse names (forEach, every, some),
since this library is trying to smooth over the native language it makes
more sense to use the native names, and provide aliases for more sensible
names from other languages, not the other way around.
Note this doesn't change any external usage, it just makes more sense.
This should also be useful for abstraction purposes for building underscore
functions, something like:
addFn('some', {has_native: true, our_version: function () {...}})
this way we could feature detect on load for native versions and build a
function, and also have the option to turn off native versions for testing
our implementation.
I Also standardized the comments to look like:
Delegates to JavaScript 1.x's native y if available.