July 25, 2012 - TC39 Meeting Notes
allen at wirfs-brock.com
Mon Jul 30 14:20:00 PDT 2012
On Jul 30, 2012, at 1:08 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> 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.
> The JSFixed project had Object.extend among its curated/moderated outcomes and I think it's a reasonable request. We rolled up Function.prototype.bind into ES5 in spite of several differences among the leading implementations (Dojo hitch, Prototype bind, etc.) and we changed the ES5 draft as we went.
Adding Object.extend is not totally comparable to adding Function.prototype.bind in ES5. The big difference is that the core semantics of the various framework provided bind functions and the ES5 bind were essentially identical. The differences only involved very obscure edge cases. This enables the ES5 bind to replace the frameworks' binds (and visa versa) with minimal disruption. There isn't anything like a universally accepted semantics for Object.extend. In particular, the semantics proposed  by JSFixed is different from the semantics defined for that same name by prototype.js . Neither of them correctly deal with accessor properties.
I think the JSFixed proposal  (and its associated issue discussion ) is a strong indication that there is significant perceived utility in a feature that enables bulk replication of properties from one object to another. However, there is almost no discussion in  of the compatibility impact of standardizing a function named Object.extend. Given that and the semantic issues (handling of accessor, etc.) I don't think the the exact JSFixed proposal is particularly reasonable. More strongly I think that adding a standard function named Object.extend is likely to be disruptive. I don't really object to a polyfillable function that has the same semantics as that proposed for := as long as it does have a name that conflicts with widely used legacy code. I do, however, question the necessity of such a function in light of the current adequate support provided by frameworks.
>> 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.
> This is not a sufficient argument on its face, since we got bind into ES5 in spite of variation.
I really think the situation is different this time. The commonly used semantics of ES5's bind did not differ significantly any other widely used implementation of a Function.prototype.bind method. so replacing one with the other wasn't disruptive. Object.extends and similar but differently named or located framework functions are not nearly as well aligned in their core semantics.
> Anyway, given the issue I raised about lack of writability being hard to test, or really: unlikely to be tested in practice, I don't think := (a good idea) motivates configurable+non-writable.
yes, a separate issue. I still think configurable+non-writable is defendable (actually better) but it's a pretty minor issue that I won't loose sleep over.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss