Re: Strategies for standardizing mistakes

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 
specifics),

- 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.

Received on Friday, 16 October 2009 04:56:03 UTC