Draft of Function.prototype.bind.

Brendan Eich brendan at mozilla.com
Thu Nov 6 20:04:37 PST 2008


On Nov 6, 2008, at 5:11 PM, David-Sarah Hopwood wrote:

> Brendan Eich wrote:
>> On Nov 4, 2008, at 10:52 AM, David-Sarah Hopwood wrote:
>>
>>> Brendan Eich wrote:
>>>> We'll make regexps non-callable in a future release whose numbering
>>>> allows us to break compatibility for all the users who may be  
>>>> relying on
>>>> this JS extension.
>>>
>>> What's wrong with that release being the one that first supports  
>>> ES3.1
>>> (so that in ES3.1, native objects are callable iff they are  
>>> functions)?
>>
>> Maybe. Let's finish ES3.1 first.
>
> You can always remove callable regexps before ES3.1; my point was that
> at least one technically incompatible release will be needed in order
> to support ES3.1.

So what? "Technically incompatible" as you use it refers to a number  
of concessions to reality in ES3.1, breaking compatibility with parts  
of ES1-3 that were never implemented. Or else to ES3.1 adding property  
names in standard objects, which is not comparable to changing or  
removing something like callable regexps.

Removing callable regexps breaks Mozilla- and/or Safari/KHTML-specific  
code that invokes regexps, with fail-stop exceptions. Speaking for  
Mozilla, we would rather not make the major-version-number change I  
mentioned (cited above) solely for ES3.1 -- we have a few other APIs  
to break.

But that's our business, no need to argue about it here.

What we should argue about is how much ES3.1 might actually break (not  
in theory, and not based on paper differences with ES1-3 where no  
browser implemented what ES1-3 specified).

Adding ES3.1 Object.* extensions is not likely to break anything.

JSON is another issue.

Removing ES3 syntax or semantics from ES3.1 in the default (non- 
strict) mode is suspect. Anything in the latest ES3.1 drafts that  
removes spec-parts outright should be reviewed carefully.

Certain changes to semantics (e.g. Date.parse preferring ISO 8601)  
that improve interoperation, compared to the current implementation- 
defined ES1-3 spec *and* browser reality, are experiments that we've  
already agreed to try, with mandatory implementation and testing  
against the web before spec finalization.


> Annexes D and E of the Kona draft.

Thanks, I am reading. We've been over all of these points many times,  
in ES4 and ES3.1 contexts on the lists and in committee.

But again, the Annex D items provoke a "so what?" reaction. These  
items (memoized standard constructors/prototypes, order of evaluation  
bugs in ES1, RegExp.prototype being a RegExp instance) are not even  
incompatibilities against "reality", meaning what most or all browser  
implementations do.

Annex E starts with format-control char non-stripping and BOMs-as- 
whitespace, and for (x in null) or for (x in undefined) not throwing.  
Again: reality (and nothing like removing a long-standing  
implementation extension).

The RegExp literal evaluation change will fix an ES3 bug (we have the  
bug reports; see https://bugzilla.mozilla.org/show_bug.cgi?id=98409  
and its dups). We will give it a try some time in the first half of  
next year, in a Firefox pre-release.

The last three items in Annex E may be problematic. They are not  
implemented by any browser, AFAIK.


> Also, any addition of a property (of one of the built-in objects) or a
> global (such as 'JSON') is a theoretical incompatibility, since it  
> would
> have been possible to write code that depended on the non-existance of
> that property or global.

Yes, I know. This is not just theoretical in connection to ES3.1.  
Facebook has (had, I hope) a JSON codec that started like so:

if(!this.JSON){
JSON=function(){function f(n){return n<10?'0'+n:n;}
Date.prototype.toJSON=function(){return this.getUTCFullYear()+'-'+
. . .
}

Unfortunately it was not based on json2.js -- its methods were named  
Encode and Decode. Hard failure in an ES3.1-supporting browser.

IE8 beta 2 and Firefox 3.1 betas have JSON, so at least two vendors  
are taking the costs for this incompatible change now. We do not have  
time or risk tolerance to take on more, speaking for Firefox, given  
the unfinished ES3.1 spec.

A given non-syntactic extension is one of
1. a new global property;
2. a new prototype property;
3. a new constructor property.

TC39 has generally avoided adding new globals; JSON is "it" for ES3.1  
(AFAIK), and since Murphy was an optimist, it is breaking some extant  
content.

A new Object.prototype property shows up as a global property and may  
break object-detecting scripts, so that's out. Of course, 3.1 extends  
ES3's Array.prototype methods based on reality, and adds toJSON to  
other non-Object prototypes. The reality-based precedents that give us  
hope we can get away with these are browser implementations of the  
Array extras, and common Ajax usage of JSON codecs that probe for  
toJSON.

But yes: JSON is already breaking code.

By comparison, extending constructors is pretty safe based on  
experience so far. We've done it in past releases for Array and String  
"static generics", e.g. Array.slice(arraylike, start, end).

The main issue for ES3.1 is to get to the "candidate recommendation"  
degree of spec completeness, where implementations can support 3.1 and  
attempt to evangelize authors of the few web pages or apps that might  
be bothered by the changes in 3.1.

If we get there soon, great -- but that does not mean we will roll to  
"Mozilla 2" just for that reason, or remove callable regexps at the  
same time. Removing is a bigger compatibility risk than adding.

/be



More information about the Es-discuss mailing list