Bound instance-function vending (was RE: Arrow binding)

Angus Croll anguscroll at
Sat Apr 28 11:13:37 PDT 2012

I'm sorry that I could not reply to the multiple replies I got last
weekend. Simply can't get the time - plus I have a phobia of fan-out
replies (an issue with mail-based discussion groups?)

In any case here's a potted reply that addresses at least some of the

1) Kevin et al suggested YAGN call/apply on (non-method) functions. Here's
a pretty neat example where call/apply is a perfect fit for standalone
functions - and would break if replaced with fat arrows.

It's a simplified version of a a localStorage function (itself a mixin BTW)
which defines standard encoding methods and then mixes in whatever storage
technique is available to the browser. (An added bonus of having functions
here, aside from privacy, is that we can employ hoisting to move the
implementation nitty-gritty to the bottom, so as not to obscure the core

2) Brendan et al pointed out that we already have hard |this| binding in
the form of Function::bind.

Yes, but bind is so blatantly explicit in its intention, the probability of
surprise is almost certainly less than with arrow functions, whose hard
lexical binding will surely come as a surprising side effect to many.

3) Several people suggested that there is a strong desire for a more
intuitive form of |this| binding.

Yes, people get confused by this binding; even though it is not hard to
learn the rules, and I know them very well, I still trip over them
sometimes. But unless we are going to introduce a "hella strict" mode that
reverts all previous rules of |this| binding, yet another rule will just
add to the morass.

Most of the "yay, fat arrow" comments I've seen from the dev community are
celebrating its brevity, I expect many of the authors have zero knowledge
of the lexical binding implications (why would they, unless they came from
CoffeeScript?). Now matter how much we justify fat arrow behavior as part
of  a long term vision, to many it is going to be a hidden, and unwanted
side effect.

At least introduce thin arrow at the same time, as a carrot to lure who
just want (and just expect) an abbreviated function syntax.

On Mon, Apr 23, 2012 at 3:01 PM, Brendan Eich <brendan at> wrote:

> Brendan Eich wrote:
>> No, in any such prototype-getter-makes-bound-**function scenario, we
>> would need memoization, so that
>>  o.m === o.m
>> (Edit: I see you mention this below.)
> The real problem is better captured by showing the prototype p and two
> instances, o and q:
>   p.m === p.m
> should be true. So should
>  o.m === o.m
> and
>  q.m === q.m
> but what about
>  o.m === p.m
> and
>  o.m === q.m
> JS requires distinct bound function identity from the unbound p.m
> identity, so false and false.
> If we managed to extend JS with a classy declarative syntax that enabled
> vtables, while keeping functions first class (at the price of
> prototype-chain mutation: assignment to override, or shadow; also of course
> delete), then we might well want true and true. But there would be no way
> in JS itself to implement such magic in terms of properties (data or
> accessor, doesn't matter) with function values.
> This is why I continue to think that we won't see what Alex predicted:
> prototype getter method vending. We haven't see it much in the wild yet
> either.
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list