July 25, 2012 - TC39 Meeting Notes

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 30 16:01:03 PDT 2012


On Jul 30, 2012, at 2:56 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> 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.
> Could be, but there were differences:
> 
> https://mail.mozilla.org/pipermail/es-discuss/2012-January/019382.html
> 
> I think you're on thin ice arguing this was so much less signfiicant than Object.extend (or let's say Object.update).

Perhaps.  I think the most important compatibility situation is when the old and new names are the same.  For example, Function.prototype.bind or Object.extend.  I understood that Function.prototype.bind was more common before ES5 than it may have really been.  However, in my reading of the MooTools docs (http://mootools.net/docs/core/Types/Function#Function:bind ) it sounds very similar to ES5 bind

> 
>> Object.extends and similar but differently named or  located framework functions are not nearly as well aligned in their core semantics.
> 
> First, "differently named" applied to bind precursors, e.g. Dojo's hitch.
> 
> Second, here's a post from jresig years ago:
> 
> https://mail.mozilla.org/pipermail/es-discuss/2008-July/006709.html
> 
> This is out of date, but note how for-in is used in all cases. There's a lot of common ground here, and some uncommon bits that look not a whole lot bigger or different-in-kind from the bind/hitch/etc. ones we overcame in ES5.

The JSFixed proposal uses getOwnPropertyNames rather than for-in and I can't imagine that we would adopt a semantics that copied inherited properties similarly to a for-in based implementation.  Similarly, I can't imagine that we wouldn't correctly handle accessors.  If a new method has to be polyfillable back to ES3 then its semantics needs to be more limited.  A much better job can be done if you only have to polyfill for ES5.  But that doesn't really provide anything new. If it is important, why isn't somebody in the community evangelize  a sound de facto standard ES5 level extend-like function that all frameworks could adopt. TC39 isn't necessary for such a thing to be widely adopted.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120730/4e536508/attachment.html>


More information about the es-discuss mailing list