Strategies for standardizing mistakes
jimb at mozilla.com
Thu Oct 15 21:54:07 PDT 2009
On 10/15/2009 02:18 PM, Allen Wirfs-Brock wrote:
> Maciej's thought experiment touches upon the fundamental evil of host objects. In the presence of host objects there is no firm foundation for understanding the semantics of an ECMAScript program. Adding some additional restrictions on host objects only reduces the insanity but doesn't eliminate it. That's why some of us would like to see ECMAScript semantics expanded so that all of the essential characteristics of Web APIs can be directly expressed in the ECMAScript language without having to use the host object loophole (and would like to set any Web API features that can't be support with rational ES features on the deprecation path).
It's not clear to me how this would win.
Suppose the language as standardized provided ways to:
- define reluctant properties or values that masquerade as undefined,
for 'document.all' emulation,
- define catch-all getters and setters sufficient to implement the cases
recently brought up in the discussions about WebIDL (I forget the
- define "split objects" or something similar, to get a global object
that behaves the way the web requires, and
- do other wretched but necessary things I haven't learned about yet.
If these features were in the standard, then people would use them in
new code. This seems like a recipe for maximizing the spread of these
very odd semantics.
And since it's been demonstrated that implementers are willing to
introduce contra-standard behavior into their ES engines to be
compatible with the de facto web with reasonable performance, I don't
understand the argument that delimiting the existing kludges in the
standard would somehow constrain future insanity. It never has before.
That is, a language standard alone isn't strong enough socially to
contain the malaise.
What might be strong enough is a public discussion process that is
responsive enough for innovators but inclusive enough to give ideas a
broad vetting. Obviously, not everything can be standardized before
anyone implements it, but there should be a public rough vetting process
that a reasonable participant can plausibly believe will improve his/her
designs. I'm assuming that, if document.all had been discussed before a
broader audience, its problems could have been avoided.
If I'm debating straw man arguments, that wasn't my intention. I may
have simply misunderstood what people meant; I'm certainly ignorant of
the history. But it seems to me that public discussion, even of
leading-edge ideas, is the only way to win.
More information about the es-discuss