FWIW, I think the reason the goog version is so complicated is because it
supports partially applying arguments when you first use goog.bind (which is
not something we’re doing).
But I definitely would like to hear why it’s important for two bound methods to
be equivalent. I’m probably missing something, but I can’t see where it would
matter.
Caching the closure seems like it just adds bulk to instances and make an app
use more memory.
Probably the most common use case of Language.closure is for event listeners.
If the event listener is transient, it can be cleaned up by garbage collection.
If it’s cached to the instance, it’ll live for the life of the instance. Seems
like a down-side to me.
Harbs
> On Jan 5, 2022, at 6:37 PM, Harbs <harbs.li...@gmail.com> wrote:
>
> 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
>> <mailto: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)
>
