ES3 Specification oddness.

Brendan Eich brendan at
Sun May 18 22:02:28 PDT 2008

On May 18, 2008, at 8:10 PM, Mark S. Miller wrote:

> Is this intended or a mistake?

It's intended, it goes back to ES1 drafts written by the Microsoft  
lead with agreement from all participating in TG1 back then (1996-1997).

> Do JavaScript implementations obey this
> peculiar behavior?


js> function f(){}
js> f.prototype = Date
function Date() {
     [native code]
js> o = new f
Function.prototype.toString called on incompatible object
js> o.prototype = 42
js> o.prototype
Invalid Date

(SpiderMonkey shell, same as in Firefox.)

Rhino follows the spec, and I'm pretty sure (can't test, no PCs at  
home) IE does too. Safari does not, looks like a JavaScriptCore bug.  
IIRC, Opera does now, having recently fixed a long-standing bug.

> Do programs depend on it?

I don't know of any, but we've been down this road before. Without a  
widely distributed browser trying out a change from the standard (de- 
facto or de-jure) at beta scale or better, we can't prove a negative.  
We know from past attempts of similar changes that the odds are not  
good. It's not encouraging if IE and Mozilla-based engines agree with  
ES1-3 here, as IE and (long ago) the Mozilla progenitor  
implementation in Netscape browsers set the de-facto standard.

There's no point borrowing trouble here, IMHO. I agree we want to  
separate read-only from no-override-allowed, but in new, compatible- 
because-opt-in territory. Hence ES4 classes with const and final as  
separate attributes.


More information about the Es4-discuss mailing list