Re: Improving Function.prototype.bind

just to make it more concrete for those interested: http://webreflection.blogspot.com/2012/01/introducing-objecthandler.html IDL Like description and code ... to me this is a much faster/easier/better solution than Function#bind ... unshimmable for IE < 9 but ... you know, some wrapper could do th

Re: Improving Function.prototype.bind

On Jan 9, 2012, at 12:29 AM, David Bruant wrote: > Le 09/01/2012 06:29, Brendan Eich a écrit : >> >> On Jan 8, 2012, at 7:20 PM, John J Barton wrote: >> >>> On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich wrote: Firebug uses a library bind a lot, and we continually struggled with the me

Re: Improving Function.prototype.bind

sorry, wrong debug, currentTarget is always the expected one ... my bad On Mon, Jan 9, 2012 at 10:44 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Bear in mind e.currentTarget may be undefined e.g. in an about:blank > page > > document.addEventListener("click", function (e) >

Re: Improving Function.prototype.bind

indeed ... inline functions are problem number 2, anonymous or not, unless the removeEventListener is not performed inside the function itself so that at least the function name could be reused while if anonymous and "use strict" is in place there's no way to know which function is it. However, tw

Re: Improving Function.prototype.bind

Le 08/01/2012 19:47, John J Barton a écrit : (...) window.addEventListener('load', boundOnLoad, false); ... window.removeEventListener('load', boundOnLoad, false); The JS method 1) must be bound to the correct object 2) be reference-able for the removeEventListener. This combination p

Re: Improving Function.prototype.bind

Just to make the second proposal easier to understand: // abstract __proto__ var AbstractEventHandler = { // invoked when events are fired handleEvent: function (e) { var events = this.events, type = e.type ; if (events.hasOwnProperty(type)) { events[type].call(t

Re: Improving Function.prototype.bind

Bear in mind e.currentTarget may be undefined e.g. in an about:blank page document.addEventListener("click", function (e) {console.log(e.currentTarget)}, false); would be null On Mon, Jan 9, 2012 at 9:29 AM, David Bruant wrote: > Le 09/01/2012 06:29, Brendan Eich a écrit : > > On Jan 8,

Re: Improving Function.prototype.bind

Le 09/01/2012 06:29, Brendan Eich a écrit : On Jan 8, 2012, at 7:20 PM, John J Barton wrote: On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich > wrote: Firebug uses a library bind a lot, and we continually struggled with the memoization problem; we did not try t

Re: Improving Function.prototype.bind

I would be more than happy to go on with "libraries first" approach as long as we don't have to wait 6 years before a needed feature is going to be considered. I have also raised the problem because it is in my opinion underestimated but mainly because I would like to avoid the fragmentation of im

Re: Improving Function.prototype.bind

Thanks, good to survey again -- we did when considering bind for ES5 (then 3.1 IIRC). Andrew Dupont's JSConf.us 2011 talk covered the particular Prototype history too. http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-extending-built-ins-5211542 /be On Jan 8, 2012, at 9:2

Re: Improving Function.prototype.bind

On Jan 8, 2012, at 7:20 PM, John J Barton wrote: > On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich wrote: >> 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 eve

Re: Improving Function.prototype.bind

Just a bit of back story on Function#bind because I think it's good to know. Prototype's Function#bind was based on the 2004 post "Object-Oriented Event Listening through Partial Application in JavaScript" by Daniel Brockman: http://web.archive.org/web/20100901172230/http://brockman.se/2004/method-

Re: Improving Function.prototype.bind

On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich wrote: > > 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. > > I'm not asking for a

Fwd: Improving Function.prototype.bind

Sorry about the format mangling. Resending with simpler formatting which hopefully won't get mangled in transmission. -- Forwarded message -- From: Mark S. Miller Date: Sun, Jan 8, 2012 at 5:05 PM Subject: Re: Improving Function.prototype.bind To: Brendan Eich Cc: John J B

Re: Improving Function.prototype.bind

On Sun, Jan 8, 2012 at 3:35 PM, Brendan Eich wrote: [...] > That's not totally clear now in light of Mark's emulated WeakMap not > leaking in practice. > [...] That's a much stronger claim than I would be willing to make. My emulated WeakMaps leak much less that one would expect, and indeed les

Re: Improving Function.prototype.bind

On Jan 8, 2012, at 12:29 PM, John J Barton wrote: > On Sun, Jan 8, 2012 at 11:39 AM, Brendan Eich 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

Re: Improving Function.prototype.bind

On Sun, Jan 8, 2012 at 11:39 AM, Brendan Eich 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. I believe we have already lamented our limited ability to analyze JS

Re: Improving Function.prototype.bind

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"? >baz.boundOnLoad = baz.onLoad.bind(baz); // bah, JS voodoo > In my code I now have a function _bindListeners() called from initialize() > where I list all of this goop. T

Re: Improving Function.prototype.bind

On Thu, Jan 5, 2012 at 11:47 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > ... > P.S. is it really just me that see the problem with current bind ? > > On Fri, Jan 6, 2012 at 2:22 AM, Brendan Eich wrote: > >> On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: >> >> Right now the

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 10:02 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: [...] > 1. everyone can WeakMap = function () {}; anywhere >>> >> >> Again, no they can't because all whitelisted global variables are >> unassignable. >> >> > it's a var WeakMap in the global scope ... still

Re: Improving Function.prototype.bind

Maybe interesting for others too, since we talked about WeakMap a lot in this thread: My essential polyfill here: https://gist.github.com/1571878 100% code coverage here: https://gist.github.com/1571887 Best Regards, Andrea Giammarchi ___ es-discus

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 6:56 PM, Mark S. Miller wrote: > > > On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> that whole variable can be redefined or used as communication channel ... >> I really don't understand what is the problem. > > > The variable

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 9:27 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > that whole variable can be redefined or used as communication channel ... > I really don't understand what is the problem. The variable "Object"? No, in SES that's unassignable. As layered on ES5, we enforc

Re: Improving Function.prototype.bind

that whole variable can be redefined or used as communication channel ... I really don't understand what is the problem. The returned bound once object could be frozen without problems but if the function is private with the gist I have posted: 1. you cannot redefine Object.prototype at all 2.

Re: Improving Function.prototype.bind

m:* Mark S. Miller > *Sent:* Friday, January 06, 2012 5:53 PM > *To:* François REMY > *Cc:* Brendan Eich ; Andrea > Giammarchi; > es-discuss > *Subject:* Re: Improving Function.prototype.bind > On Fri, Jan 6, 2012 at 1:29 AM, François REMY > wrote: > >> Such an

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 1:50 AM, David Bruant wrote: > Le 06/01/2012 10:40, Andrea Giammarchi a écrit : > > if WeakMaps are so smart ... it means we cannot shim them without causing > leaks in non WeakMap ready browsers since no magic will happen,objects as > keys will simply be persistent in the

Re: Improving Function.prototype.bind

, right? Or am I missing something? From: Mark S. Miller Sent: Friday, January 06, 2012 5:53 PM To: François REMY Cc: Brendan Eich ; Andrea Giammarchi ; es-discuss Subject: Re: Improving Function.prototype.bind On Fri, Jan 6, 2012 at 1:29 AM, François REMY wrote: Such an implementation would

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 1:31 AM, David Bruant wrote: [...] > David's WeakMap approach elegantly avoid this problem, because Alice and >> Bob can only communicate if they already share access to this WeakMap, in >> which case they could already communicate anyway. >> > Are you talking about > http

Re: Improving Function.prototype.bind

Le 06/01/2012 17:43, Mark S. Miller a écrit : On Fri, Jan 6, 2012 at 8:31 AM, David Bruant > wrote: Le 06/01/2012 06:03, Mark S. Miller a écrit : Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal am

Re: Improving Function.prototype.bind

ty creates an ambient communications channel. > > François > > > > -Message d'origine- From: Brendan Eich > Sent: Friday, January 06, 2012 2:22 AM > To: Andrea Giammarchi > Cc: Axel Rauschmayer ; François REMY ; es-discuss > Subject: Re: Improving Function.

Re: Improving Function.prototype.bind

Alice wouldn't normally be able to communicate 'bound' to Bob, and thus Bob wouldn't be able to read Alice's 'bound.foo'. The issue is much like ES3's mistake of evaluation a RegExp literal once to a RegExp object -- everyone executing the same code could now communicate, even if all accessible pri

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 8:31 AM, David Bruant wrote: > Le 06/01/2012 06:03, Mark S. Miller a écrit : > >> Such a built in memoization, whether by boundTo or this enhancement to >> bind itself, creates a fatal ambient communications channel. >> >> >>// initSES initialization, freezing all built

Re: Improving Function.prototype.bind

If the case I show is not a problem, as you see with AMD loaders and decent practices the problem does not exist with my approach while problems like this exists today everywhere for those exposed objects through namespaces or even modules. Attaching instances properties runtime to bound functions

Re: Improving Function.prototype.bind

Le 06/01/2012 06:03, Mark S. Miller a écrit : Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal ambient communications channel. // initSES initialization, freezing all built in primordials other than the true global // load Alice as a

Re: Improving Function.prototype.bind

Le 06/01/2012 16:54, Andrea Giammarchi a écrit : there is no security issue ... it's meant like that plus what Mark did not think about, is that if I use (function () { function callback() {} var object = {}; window.addEventListener("no way", object.boundTo(callback), false); //

Re: Improving Function.prototype.bind

there is no security issue ... it's meant like that plus what Mark did not think about, is that if I use (function () { function callback() {} var object = {}; window.addEventListener("no way", object.boundTo(callback), false); // later on window.removeEventListener("no way", o

Re: Improving Function.prototype.bind

Le 06/01/2012 12:51, Andrea Giammarchi a écrit : unreachable without reference count? do you have an example different from a private scope object that is reachable from that scope so I would not call it unreachable? I'm not sure I understand your question. In IE6 (7? 8?), written naively, even

Re: Improving Function.prototype.bind

unreachable without reference count? do you have an example different from a private scope object that is reachable from that scope so I would not call it unreachable? In any case I understand your leaks point and if WeakMap solves this, but I strongly believe no shim will be able to emulate this

Re: Improving Function.prototype.bind

Le 06/01/2012 12:23, Andrea Giammarchi a écrit : it doesn't ... as soon as you release the reference to o no leaks persists but of course until you keep o on hold those unique callbacks cannot be released ... If you're telling me that keeping only one of the object or the function alive but not

Re: Improving Function.prototype.bind

it doesn't ... as soon as you release the reference to o no leaks persists but of course until you keep o on hold those unique callbacks cannot be released ... but this would be true with WeakMap too, isn't it? In any case, boundTo is suitable for listeners and the whole point is to do not hold ma

Re: Improving Function.prototype.bind

Le 06/01/2012 11:20, Andrea Giammarchi a écrit : On Fri, Jan 6, 2012 at 10:50 AM, David Bruant > wrote: Your proposal won't be implemented in older browsers. Actually, it is very likely that your proposal would be implemented in browsers that would alrea

Re: Improving Function.prototype.bind

On Fri, Jan 6, 2012 at 10:50 AM, David Bruant wrote: > > Your proposal won't be implemented in older browsers. Actually, it is very > likely that your proposal would be implemented in browsers that would > already have weak maps. > Under these conditions. What is the benefit of a native implement

Re: Improving Function.prototype.bind

Le 06/01/2012 10:40, Andrea Giammarchi a écrit : if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen,objects as keys will simply be persistent in the WeakMap private scope Indeed. Also, Mark Miller mentionned a

Re: Improving Function.prototype.bind

Eich > Sent: Friday, January 06, 2012 2:22 AM > To: Andrea Giammarchi > Cc: Axel Rauschmayer ; François REMY ; es-discuss > Subject: Re: Improving Function.prototype.bind > > On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: > > Guys, by any chance we can go back into

Re: Improving Function.prototype.bind

if WeakMaps are so smart ... it means we cannot shim them without causing leaks in non WeakMap ready browsers since no magic will happen, objects as keys will simply be persistent in the WeakMap private scope ... does not look good, means we cannot solve this via libraries, means my initial proposa

Re: Improving Function.prototype.bind

Le 06/01/2012 06:03, Mark S. Miller a écrit : Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal ambient communications channel. // initSES initialization, freezing all built in primordials other than the true global // load Alice as a

Re: Improving Function.prototype.bind

My proposal could break existing code so it’s probably not worth a shot in ES6. Maybe in ES7, then. From: Brendan Eich Sent: Friday, January 06, 2012 12:52 AM To: François REMY Cc: Axel Rauschmayer ; Andrea Giammarchi ; es-discuss Subject: Re: Improving Function.prototype.bind What *exactly

Re: Improving Function.prototype.bind

nctions]] - return the newly created boundFunction Would that be possible? François -Message d'origine- From: Brendan Eich Sent: Friday, January 06, 2012 2:22 AM To: Andrea Giammarchi Cc: Axel Rauschmayer ; François REMY ; es-discuss Subject: Re: Improving Function.prototype.bind O

Re: Improving Function.prototype.bind

Le 05/01/2012 23:10, Andrea Giammarchi a écrit : leaks When a function has no strong reference, the associated entry in the first WeakMap (which is the second level of weakmap) can be GC'ed. When an object has no strong reference, all entries in second-level WeakMaps can be collected. I don't s

Re: Improving Function.prototype.bind

same thing this does var bound = Object.bind(Object); bound.foo = capabilityBobShouldntGet; // who does this ? var HAH = bound.foo; ... so I am missing your point I guess ... but my proposal wants to return always same object for 99.9% of usage out there ... On Fri, Jan 6, 2012 at 8:55 AM, Mark

Re: Improving Function.prototype.bind

In your proposal, what does this code sequence do: Object.boundTo(Object).foo = capabilityBobShouldntGet; var HAH = Object.boundTo(Object).foo; ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Improving Function.prototype.bind

most JS developers use what their library/framework provide and the bind is most of the time transparent. Libraries developers simply use bind as a Santa Claus ES5 gift so they don't bother thinking about the pattern they are forced to use, they just use bind the way they can but again, not relyin

Re: Improving Function.prototype.bind

Such a built in memoization, whether by boundTo or this enhancement to bind itself, creates a fatal ambient communications channel. // initSES initialization, freezing all built in primordials other than the true global // load Alice as a confined object graph // load Bob as a confin

Re: Improving Function.prototype.bind

On Jan 5, 2012, at 4:47 PM, Andrea Giammarchi wrote: > Guys, by any chance we can go back into the topic? You'll have to polyfill Function.prototype.bind in the current world of pre-ES5 browsers. Why not then go on to wrap it in a memoizing version that uses a WeakMap if available (emulated wit

Re: Improving Function.prototype.bind

Guys, by any chance we can go back into the topic? I was not thinking about changing the meaning of "this" in a function, also Python sends explicit self context as first argument so things are slightly different in any case Point is: - bind was one of the most needed/used Function.prototyp

Re: Improving Function.prototype.bind

> I do not believe (Axel) that the spec's Reference internal type is helpful as > an externally-visible part of the language in any of this. I believe you, I know nothing about how references are actually implemented. Python works like this: class Foo: def bar(): pass

Re: Improving Function.prototype.bind

On Jan 5, 2012, at 8:08 AM, François REMY wrote: > >> > >> It’s a shame that we are really close in JavaScript, with the ECMA-262 > >> specification using references. > >> > > As things are going, things are not going to change. The strong desire to > avoid any behavior breakingchange between

Re: Improving Function.prototype.bind

7;t hesitate too much... or you will fragment the web scripting with tons of "hyper" languages like CoffeeScript. It isn't a good idea. Or at least it doesn't seems to me. François From: Axel Rauschmayer Sent: Thursday, January 05, 2012 10:24 PM To: François REMY Cc: An

Re: Improving Function.prototype.bind

leaks, performances, as example, are the first things I have in mind when I look at that code ( assuming I understand how WeakMap works there ) Function.prototype.bind could have been implemented via libraries ( as Prototype did ) as well so I don't get your argument, sorry. My point is that Func

Re: Improving Function.prototype.bind

Hi Andrea, It seems that what you want can be implemented as a library [1] (actually you did it as well in your blog post). In this gist, a cache is used. In a nutshell, it is a '(function, object) -> boundFunction' mapping. I used 2 levels of WeakMaps to achieve this. I don't think a native impl

Re: Improving Function.prototype.bind

> As things are going, things are not going to change. The strong desire to > avoid any behavior breakingchange between ES5 and ES6 actually makes it > impossible to fix a lot of issues. I’m starting to think Google may be right > to start over a new language, the comitee is too conservative abo

Re: Improving Function.prototype.bind

all the time since I widely use private methods and I reuse them per each created instance of a specific "class" The boundTo() approach would make the method still private, immutable out there, and reusable per each instance/object I need. // stupid useless example ... just as concept var Counter

Re: Improving Function.prototype.bind

> that would not solve much 'cause you can bind a function to a single object > and no more. Isn’t that the most frequent use case? Do you have examples where you bind the same function to several objects? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschm

Re: Improving Function.prototype.bind

>> >> It’s a shame that we are really close in JavaScript, with the ECMA-262 >> specification using references. >> As things are going, things are not going to change. The strong desire to avoid any behavior breakingchange between ES5 and ES6 actually makes it impossible to fix a lot of issues.

Re: Improving Function.prototype.bind

that would not solve much 'cause you can bind a function to a single object and no more. My proposal is object related so that eventually, even if you forget to explicitly drop already bound callbacks, those stacks should be GCed automagically and memory speaking it should be safe. @Jake I find t

Re: Improving Function.prototype.bind

On Jan 5, 2012, at 14:54 , Andrea Giammarchi wrote: > Here the whole post with better examples plus the proposed solution that > would be nice to have in JS.Next > http://webreflection.blogspot.com/2012/01/improving-functionprototypebind.html I don’t use bound() and function expressions very of

Improving Function.prototype.bind

I have thought it may be interesting to receive some comment here too ... so here the short summary: genericCallback.bind(sameObject) !== genericCallback.bind(sameObject) quite inconvenient for listeners and leading to uncomfortable patterns ( store the bound reference somewhere and get it back l