July 25, 2012 - TC39 Meeting Notes

Brendan Eich brendan at mozilla.org
Sat Jul 28 18:58:30 PDT 2012


Allen Wirfs-Brock wrote:
> I really think in a language where we have both [[Put]] and 
> [[DefineOwnProperty]] semantics that we really need both = and :=

I can buy that, and I'm glad you mention := as it is not just an 
assignment operator (e.g. in Pascal or Ada), it's also Go's 
declare-and-init operator. It has the right characters, fuzzy meaning 
from other languages, and the critical = char in particular. I could see 
adding it as a winning and better user-interafce to 
Object.defineProperty and even Object.extend.

However, Object.extend is usable in old and new browsers, with polyfill. 
Object.extend is the cowpath trod by many happy cows. Requiring a 
transpiler is harsh. Should we entertain both := and Object.extend, or 
perhaps the better name to avoid colliding with PrototypeJS, 
Object.define or Object.update?

> Finally, this discussion caused me to realize that I messed-up  on an 
> important detail when I prepared and presented the class semantics 
> deck (http://t.co/PwuF12Y0) at the TC39 meeting.
>
> In the deck, I incorrectly stated that I was proposing that the 
> attributes associate with a property created via a concise method 
> definition (in a class or object literal definition) should have the 
> attributes {writable: true, configurable: false}. I had a hard time 
> defending that choice at the meeting.

It wasn't so obviously wrong, it's what var binds outside of eval.

However TC39 favored configurable: true as well as writable: true, to 
match JS expectations, in particular that one could reconfigure a data 
property (which is what method definition syntax in a class body 
creates) with a workalike accessor.

That's in the meeting notes, and I still think it is the winner. More below.

>  There is a good reason for this, that attribute combination was never 
> what I intended but I ended up trying to defend what I wrote rather 
> than what I really wanted.

Without presenting :=, what you wanted had no precedent and is "weak 
integrity", the kind of half-measure MarkM and I decried.

> Instead, what I meant to say was {writable: false, configurable: 
> true}. Brendan and perhaps others have in the past expressed that this 
> is a strange combination because it disallows assigning a value but 
> changing the value can still be accomplished using 
> Object.definePropertry.  The above discussion gives me the concepts 
> necessary to explain the motivation for this design.   It's simple, 
> this attribute combination disallows using [[Put]] updates while 
> allowing [[DefineOwnProperty]] updates, just as described above.

It's not that simple, alas. Even if we add := and users come to 
understand and use it well alongside = (requiring transcompilation in 
the near term), do users increasingly opt into "use strict"? Not clear. 
Yet "use strict" is the better path to find failed assignment attempts 
to non-writable properties expressed using using =, and replace those 
with :=.

Without "use strict", assuming good test coverage, one has to noticed 
that = failed to update the LHS. Tests rarely flex their bindings after 
reassignment to check for non-writable silent non-strict failure, and 
real code is even less prone to doing so.

On balance, I like := as a complement to =, but I'm leery of 
new-version-only thinking that leaves out Object.extend or better-named 
use-cases. And I am skeptical that any of this means non-writable 
configurable is a sane attribute combo for methods.

/be



More information about the es-discuss mailing list