Oh. I think I understand. removeEventListener needs to reference the same function as addEventListener which needs to be unique to an instance but match on subsequent checks.
That’s what I was missing. Never mind, and sorry for the noise… ;-) Although, I wonder if there’s some way we can optimize “one time” event listeners… Harbs > On Jan 5, 2022, at 7:15 PM, Harbs <harbs.li...@gmail.com> wrote: > > 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 >> <mailto: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) >> >
