July 25, 2012 - TC39 Meeting Notes

Brendan Eich brendan at mozilla.org
Mon Jul 30 16:12:03 PDT 2012


Allen Wirfs-Brock wrote:
> 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

Read all the docs, not just MooTools. Dojo's hitch takes a string or a 
function (if string, it looks for that method "in scope"). PrototypeJS 
didn't forward new attempts to the target. Etc.

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

We were talking about precedent in libraries, not JSFixed, but ok.

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

It may not matter. The rule has been "Object.prototype is verboten" and 
the pattern generally uses an object (literal, even), not an array whose 
prototype has been extended by assignment, as the source. So no 
proto-pollution occurs in practice.

So I suspect we would be fine spec'ing Object.getOwnPropertyNames. That 
is on the level of the changes made from progenitor bind-like functions, 
in reality (due to the best-practices mentioned above).

>  Similarly, I can't imagine that we wouldn't correctly handle accessors.

Right, but the precedents predate ES5 so this is no surprise. It's sort 
of like Prototype's not forwarding new, arguably "worse" but hard to say.

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

Now you're picking a fight. The point is *not* to provide something new 
if the use-case would be met by an API that can be polyfilled -- as many 
use cases can, since the call sites pass *object literals*.

What the API provides is the ability to do without a transpiler. That's 
a big deal.

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

We did not insist on such a condition when we put bind into ES5. But now 
you are definitely rehashing something I thought we were past: we do not 
require one winner in detail to adopt something. If we did, nothing much 
would get adopted.

> TC39 isn't necessary for such a thing to be widely adopted.

That applies to bind-like functions too and it's irrelevant.

/be


More information about the es-discuss mailing list