Guys, by any chance we can go back into the topic?<div>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 ....</div>
<div><br></div><div>Point is:</div><div>  - bind was one of the most needed/used Function.prototype ever, the reason ES5 adopted it out of Prototype library</div><div>  - bind is over-enginered for 90% of use cases and it easily leads to anti-patterns due inability to retrieve already bound functions/objects and the need to address somewhere everything if we want to remove, as example, a listener</div>
<div>  - bind, as it is, is more than fine, and developers got use to it, it does not mean that developer could understand an Object.prototype related method able to create and retrieve the unique function bound with that object as context</div>
<div><br></div><div>I am seeing stuff like this everywhere</div><div><br></div><div>this._boundMethod = this.method.bind(this);</div><div><br></div><div>and in my opinion is even ugly to read ... first of all is redundant all over the place, secondly the bound method is, in this way, easily exposed outside.</div>
<div><br></div><div>A private scope per each instance so that bound method would be a private variable makes even less sense ... plus bind, used with the single context argument, is a context matter, and a single context argument, should never be recreated unless strictly necessary but today I have still never seen the usage for a new bound function/object used as freshly new created object.</div>
<div><br></div><div>Nobody is using/creating two context bound on purpose so that</div><div><br></div><div>sameCallback.bind(sameObject)</div><div>should always be ===</div><div>sameCallback.bind(sameObject)</div><div><br>
</div><div>since the scope the callback has been created won't ever change during app lifecycle, and accordingly it does not make sense at all to create two different results/functions/objects</div><div><br></div><div>
I don't want to break bind as it is, all I am proposing is to bring Object.prototype.boundTo/asContextOf in core so that GC life is easier and performances much fasters than whatever WeakMap or proper method, to avoid leaks, could do.</div>
<div><br></div><div>sameObject.boundTo(sameCallback) === sameObject.boundTo(sameCallback)</div><div><br></div><div>is a simple method that could change 90% of frameworks out there and it's shimmable, through my code, or others libraries.</div>
<div><br></div><div>Any thoughts on this ?</div><div>It's just needed, so if you have a better idea, since those exposed until now do not scale or are not faster/shimmable, I'd like to listen to it.</div><div><br>
</div><div>Thanks and Best Regards</div>