On normal modern systems it’s roughly quivalent to this:
function(fn, selfObj, var_args){
return /** @type {!Function} */ (fn.call.apply(fn.bind, arguments));
}.apply(null,arguments);
Here’s the code:
goog.bindNative_ = function(fn, selfObj, var_args) {
return /** @type {!Function} */ (fn.call.apply(fn.bind, arguments));
};
goog.bind = function(fn, selfObj, var_args) {
// TODO(nicksantos): narrow the type signature.
if (Function.prototype.bind &&
// NOTE(nicksantos): Somebody pulled base.js into the default Chrome
// extension environment. This means that for Chrome extensions, they get
// the implementation of Function.prototype.bind that calls goog.bind
// instead of the native one. Even worse, we don't want to introduce a
// circular dependency between goog.bind and Function.prototype.bind, so
// we have to hack this to make sure it works correctly.
Function.prototype.bind.toString().indexOf('native code') != -1) {
goog.bind = goog.bindNative_;
} else {
goog.bind = goog.bindJs_;
}
return goog.bind.apply(null, arguments);
};
Not sure why you’d want to use two applies and one bind instead of a single
apply in:
return function() {
return fn.apply(object, arguments);
};
> Did you test this with your chsnges:
>
> var f1:Function = myInst.method;
> var f2:Function = myInst.method;
>
> trace(f1 == f2)
No I didn’t. You’re right that will likely fail. But why is that important?
Thanks,
Harbs
> On Jan 5, 2022, at 5:00 PM, Greg Dove <greg.d...@gmail.com> wrote:
>
> I would assume that goog.bind would be optimized by gcc if it can be
> (perhaps it is inlined if it uses es5 function.protoype.bind internally- I
> did not look inside it)
>
> The function naming/caching in Language.closure is important, including
> private naming conventions when they are needed for closures.
>
> Did you test this with your chsnges:
>
> var f1:Function = myInst.method;
> var f2:Function = myInst.method;
>
> trace(f1 == f2)
