Arrow binding

Alex Russell alex at dojotoolkit.org
Mon Apr 23 10:07:41 PDT 2012


On Apr 23, 2012, at 3:35 PM, Mark S. Miller wrote:

> On Mon, Apr 23, 2012 at 6:46 AM, Kevin Smith <khs4473 at gmail.com> wrote:
> I'm not sure I understand the reasoning behind "soft-binding".  If I use arrow syntax, my intention is to close over |this|.

Arrow will take on whatever meaning we decide for it to take on. You have a particular desugaring in mind, but making the call that "I'd like all of the effects of closing over |this|" vs. the value of "I'd like this not to blow-up when I de-ref it from my object" is not something that's easy to inspect for. Assuming preference for the hard version is just that, assumption.

>  Allowing a caller to change the binding of |this| will result in a violation of that closure.  In this respect, |this| within an arrow function is no different that any other closed-over variable.  I would not want a caller to be able to override the binding on any of those variables, right?
> 
> Right. I think this is the key issue regarding defaults and what arrow functions must do -- hard binding. Making this binding soft would destroy the integrity of lexical capture that arrow functions provide for "this".
> 
> Alex, <http://wiki.ecmascript.org/doku.php?id=strawman:soft_bind>, which we worked on together, implements soft binding as a simple small library. We wrote this over a year ago.

Ah, yeah, I'd actually forgotten about it.

> Since then, I've never found a need for this. Could you give a concrete example where this is useful? Do such uses justify a role beyond such library implementations? I'm inclined to YAGNI on this one.

Well, since it's much larger (code-wise) than the equivalent hard-binding method, it's not hard to see which one you'd include in a JS library. You'd need the soft version a *lot* to meet the overhead requirements of including both in a JS lib.

What syntax does, however, is a very different question and using library evidence by wrote gets you into trouble. Our view from the language perspective can be broader and can look for conceptual integrity where libraries cannot afford to.

Regards


More information about the es-discuss mailing list