Class double-bind

Brendan Eich brendan at mozilla.org
Tue Mar 3 10:55:52 UTC 2015


Allen Wirfs-Brock wrote:
>> That's precisely what I thought, until I started thinking about what
>> >  it'll actually be like to use this feature as a programmer.
>> >  
>> >  To me, this issue explains why functions are the way they are.
>
> Not my understandings.  Function declarations are the way they are because that's the way they were inMay 1995.   Function expressions got added in ES3 and added the local name binding for them.  But didn't change function declarations (probably because it would have been a breaking change).

Among other reasons :-|.

Top-level functions binding one name, instead of two, avoids the 
problems Jason cites. It may make other problems, which require 
programmers to create a second binding that is hidden or otherwise 
protected from replacement, but that's a trade-off.

Do not pretend that the `var f = function f(){}` pattern advocated by 
some is more primitive than `function f(){}`. It isn't, and it wouldn't 
have been, even if I'd had time to do function expressions in 1995.

Rather, I wanted a lightweight, top-level `let rec` analogue, not only 
for mutual recursion, but also to enable top-down presentation. That's a 
win in JS when using function declarations.

ISTM that in ES6 as drafted, anyone wanting to do what Jason showed, a 
wanted thing:

     Foo = wrapConstructorWithExtraLogging(Foo);


will need to pre-arrange with Foo's author that internal uses of Foo 
which should refer to the replacement be denoted by outer.Foo or global.Foo.

This can be done, but it is potentially a big paper-cut, or pain-in-the-ass.

Going the other way on the trade-off, trying to protect against Foo = 
{}, is not saving a p.big p-phrase -- it's kicking the can down the road 
on what looks like a bug to be smoked out.

At this point we may have to take the hit, but I'm making you read this 
to talk back to the imprecations against function declarations and their 
single bindings. Double bindings are "now you have two problems" when 
one binding is mutable -- no upside _per se_, however much you want the 
immutable inner binding (and sometimes you do not want).

/be


More information about the es-discuss mailing list