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? Yes: 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 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. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss