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...
