July 25, 2012 - TC39 Meeting Notes

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 30 12:02:53 PDT 2012

On Jul 28, 2012, at 6:58 PM, Brendan Eich wrote:

> 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?

I think we should view := as new syntax that is primarily intended to be used in combination with other new syntax such as concise methods, class definitions, super, etc. that also require transpiling for use in older versions.   It is neither more or less harsh than any other new syntax. When we incorporate new syntax we are primarily making an investment for future ES programmers.  Transition issues need to be considered but I think that for ES, the future is still much longer and larger than the past.

The problem with Object.extend is that it isn't a single cow path.  There are multiple path leading in the same general direction but taking different routes. This was the case in 2008 when we considered adding Object.extend for ES5 and it is even more so now.  We could add a completely new function such as Object.update, but I wonder if that is really needed.  Frameworks seem to be dong a fine job providing their own variants of Object.extend-like functions that are fine tuned to match their own abstraction models and other requirements.  A polyfill with semantics that are different from someone's favorite framework might just cause confusion, even if it uses a different name.  Are things still going to work if I use Object.update instead of ProtoyypesJS's Object.extend in a PrototypeJS environment?  Maybe not?  Same for other frameworks and other extend-like functions.  Rather than sowing confusion in the current ES3/5 framework world with a new polyfill, it might be better to simply leave things be WRT a standardized extends-like function.  := would be a new syntactic ES6 syntactic form that works in combination with other new ES6 syntactic forms.  Legacy code and frameworks with their own extend-like functions would all continue to work in that ES6.  New ES6 code probably doesn't need a procedural form of := (or if they do they could easily define it:  Object.update=(obj1, obj2) => obj1 := obj2; ).

Cowpath are important for telling us where the cows need to go but they are constrained by the current terrain.  Introducing an  syntactic operator such as := is like building an elevated freeway  that goes straight to the destination above the current cowpaths. It allows the old cows to continue to follow their established paths for as long as they need to, but don't constrain future high-speed travelers to following those old paths. 

>> 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.
> ...
> 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.

I made my case above. I think this is a situation where new-version-only feature design is fine (but getting there requires thinking about old versions).  The current framework writers have things under-control for current/old versions.  Sure it would have been great if there had been a standard extend-like function prior to the creation of modern frameworks, but there wasn't.  Rather than throwing ripples through the current frameworks it may be better for us to focus on how new things will be done with the new version.


More information about the es-discuss mailing list