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
