Previously, there was no way to get at the OO wrapper object.
So if a user added a custom method on to _, or defined a custom
alias, it would not be reflected in the wrapper. Now it is at
least possible, though there is no API to do it. I alluded to
making one in my commit that added _.alias() (which I recently reverted,
as it added weight to the stripped version), but honestly I think
the wrapping behavior should go in to a seperate library, not because
it is bad, but because it is an awesome pattern that I want to use
on objects other than underscore.
The intention is that underscore Consumers MUST call _.initWrapper()
in their code to allow the OO style usage, or a runtime error is thrown.
This would break backwards compatability, so for the moment I call
initWrapper myself at the end of underscore.
However, if I comment out my call to initWrapper and don't call it
in user code, then the compiler can strip an empty underscore with
no user code from 2137 -> 100 bytes. Making the user explicitly say
they want OO wrapping is the only way to achieve this, otherwise the
compiler will always keep the OO wrapper code around.
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.
