On Jan 8, 2012, at 12:29 PM, John J Barton wrote: > On Sun, Jan 8, 2012 at 11:39 AM, Brendan Eich <bren...@mozilla.com> wrote: > On Jan 8, 2012, at 10:47 AM, John J Barton wrote: > > > That is why our code is now littered with: > > BTW, which "our code"? > > Mine, Andrea's, Hewitt's Firebug at least.
Thanks, I see what you mean in Firebug. > I believe we have already lamented our limited ability to analyze JS code > patterns statistically. What does that have to do with betterBind? Any purely library (API) solution would be equally refractory to analysis. > I've used "var self" and "var that" quite a lot. It's a hack, contributes to > right marching, stutters reading, but anyway the topic is bind() and how it > might be better. I'm not selling you on var self = this;, just pointing out the alternative used by enough people that standardizing a memoizing bind has not risen to TC39's agenda. Could be it should have, but the signal is not strong and well-tuned yet -- guess we're tuning now. > More important, I want my reply to highlight a different meta-issue you > raise: the role of libraries in testing ideas. Ok. > > > > > I don't know if Andrea's solution is good or not, but I want to put another > > vote for |"this| is a problem". > > Mark made the case for avoiding a capability leak channel in .bind, > > (Mark's case relies on believing that secure JS is a goal that trumps > usability; I hope too be converted to this belief soon). Mark could remove any memoizingBind from SES, no doubt. For ES5, we were paving a cowpath as I noted (PrototypeJS etc.). > Standardizing library uses make sense, except here is an example of a > failure. The library version of bind() have exactly the problem we are > discussing here! It wasn't considered a failure by many. Where were the requests in the ES3.1/4/5 era for memoizing bind? I may have missed one, so please point it out. > Why did we end up in this (hmm) bind? Somehow the standardization process did > not anticipate this issue even though it was known? Did you read what I wrote about Prototype? None of the bind/hitch/etc. library solutions memoize, if my memory serves. Sure, you could say lack of WeakMap or equivalent practically ensured that outcome, to avoid leaks. That's not totally clear now in light of Mark's emulated WeakMap not leaking in practice. Anyway, this is all water under the bridge. What about the future? My position is still do the library work and popularize. Even if you really need a fast-track ES.next solution, the library work must come first. > Firebug uses a library bind a lot, and we continually struggled with the > memoization problem; we did not try to solve it in part because we hated > Firebug's bind: it made debugging even more painful since it messes up the > call stack. Using the ES bind() ends up not being a win, since I now have > exactly the same problems. I have a question: why is bind used so much in Firebug for event listeners, when the DOM guarantees to dispatch them with the event target bound to |this|? Way back in '95, I created event handlers but did not add bind (it had to be discovered later). But dynamic |this| binding combined with DOM event target-based listening and handling kept this properly bound. What has changed? /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
