Re: Conflicts between W3C specs and ES5?

On Nov 17, 2009, at 6:41 PM, Maciej Stachowiak wrote:

> What I don't like is the specs acting like legacy features don't  
> exist.

We are not very good actors -- no Method, no Respect for the Craft  
(Alan Rickman Dr. Lazarus voice).

I talk about legacy all the time in TC39, it may be schtick at this  
point how I can get the tasteful folks to turn eight shades of green.  
But come to our future meetings, you can partner with me in these  
comedy acts ;-).


> My message included both specific comments about __proto__ (where I  
> said I don't like the writability and wish it would die) and a  
> general statement on legacy features. This was not intended to imply  
> that __proto__ is the best test case, since at the very least  
> writable __proto__ is something we'd prefer to phase out if that is  
> possible.

Writable __proto__ for newborns (in object initialisers) is handled  
(without syntactic sugar) by Object.create in ES5, and there are sugar  
proposals in wiki.ecmascript.org. Writable __proto__ is another thing  
we'll try to kill, although I have no idea how hard a target it is  
right now.


>>> otherWindow.copyOfEvalFromYetAnotherWindow("...") throws
>>>
>>> In other words, eval's this value must be the same as the global  
>>> object that defined it, else we throw.
>>
>> What is the rationale for throwing in this last case, rather than  
>> using the explicit base object (otherWindow) as |this|?
>
> I'm not necessarily advocating this particular behavior, just  
> describing it (based on code inspection). I would guess one reason  
> to throw is to avoid answering whether the |this| value should be  
> otherWindow, or the window in which copyOfEvalFromYetAnotherWindow  
> was originally defined. I have no problem with either of those  
> alternatives, personally.

The standard ECMA-262 semantics want otherWindow -- "bound method"  
exceptions prove the rule. And eval is not a bound method of its  
window. So otherWindow seems likely to be the standard behavior, but I  
wondered if you had some deeper reason (IE compatibility?) for the  
third case.


>> I hope it won't shock you to learn that
>>
>> <!--
>>
>> and
>>
>> -->
>>
>> have been observed in the middle of external .js files loaded by  
>> <script src="foo.js"></script> :-(. Refactoring contagion vector.
>>
>> So yeah, messy. Nevertheless, ECMA-262 implementations in embedded  
>> devices with no web contacts may not care to hassle with the  
>> horrors of these old comment-hiding hacks. Informative Annex?  
>> Optional-but-normative-if-implemented section?
>
> My personal inclination would be to make it fully normative unless  
> someone actually complains about the effort of implementing it in  
> their embedded context, relative to the benefit of better aligning  
> with JS as she are spoke on the Web.

This reminds me of something else: ECMA-357, E4X as it is known, has  
CDATA XML literals. This conflicts with <!-- and --> as magic line  
comments in a future ES, not that it should stop us. We agreed at the  
last TC39 meeting to leave ECMA-357 referencing ECMA-262 Ed. 3, not ES5.

/be

Received on Wednesday, 18 November 2009 03:04:16 UTC