Re: Conflicts between W3C specs and ES5?

Quoting Brendan Eich <brendan@mozilla.org>:

> On Nov 17, 2009, at 11:03 AM, Maciej Stachowiak wrote:
>
>> On Nov 17, 2009, at 7:32 AM, Brendan Eich wrote:
>>
>>> On Nov 16, 2009, at 4:28 PM, Maciej Stachowiak wrote:
>>>
>>>>> The opportunity cost (that you spend time on trailing edge stuff  
>>>>>   instead of better leading edge work) is very high too.
>>>>
>>>> Did you look at the contents of the Wiki page? foo.arguments is    
>>>> not in there, nor is anything of a similar level of evil.
>>>
>>> You're right -- I brought foo.arguments up because it is    
>>> implemented by V8, and based on stealth-mode development combined   
>>>  with web testing. So why isn't it on that wiki page? In principle  
>>>   it should be, since it was required for web compatibility   
>>> according  to V8 developers' testing.
>>
>> You'd have to ask the authors of the page that. I assume it's    
>> because the page constitutes scratch notes and is not exhaustive.
>
> Yes, and since I opened my big mouth about foo.arguments, James now
> avers that it should be added to that wiki page. So my point stands:
> it looks like incipient over-specification, specifically of
> foo.arguments, RegExp statics, Date.parse, non-standard eval, possibly
> settable __proto__.

It's about documentation, not specification. The page is notes that I  
and others have made whilst reverse engineering existing  
implementations. This is exactly the same reverse engineering that  
other implementers must have done (since they implement the things on  
that page yet they are not otherwise documented). It seems crazy to  
make everyone do the same work over and over, always making slightly  
different choices and ending up with slightly different,  
incompatibilities.

I also stress that I have no particular desire to see foo.arguments in  
particular propagated forward. But whilst everyone else has a feature  
it is very hard to for me argue that it isn't needed for compatibility  
and, as such, I am in favour of it being documented. If we want to get  
rid of it there should be a plan for removing it from implementations,  
not an embargo on writing down how it works. Do Mozilla (or anyone  
else) have plans to remove this feature from their engine (even just  
initially as a 'trial balloon' change during a pre-release phase)?

> No big deal, it's just a wiki. But there's a big-picture issue here,
> to do with trailing edge over-kill vs. alternatives that move the
> leading edge forward. Sometimes the intersection semantics among
> browsers for a given API or syntax and semantics are so broken that
> developers avoid the feature already, and a new-and-better way can be
> promulgated (not designed by committee, but designed in the open and
> trial-implemented).

if things are avoided to the extent that they are actually unneeded  
for compatibility then they are fine to remove of course (and I would  
expect people claiming that they are unneeded who actually work on  
implementations to match their claim with changes to the  
implementation and others to provide compelling enough evidence that  
implementations are actually changed). If they are things that look  
like they can be evangelized away but are nevertheless needed today  
they should be documented with strong admonitions against their use  
and noting the possibility of removal from future versions. If they  
are things that are distasteful but unlikely to vanish (bearing in  
mind that there is a tail of useful web content going back to the dawn  
of the web ? witness the recent efforts to resurrect geocities ? this  
is a sensible default assumption) they should be grandfathered in to  
the appropriate specification.

> I do not believe we have infinite and pre-specialized labor available
> (we = all of us reading this, and our colleagues) to both over-specify
> legacy and try to move forward with better specs. Worse, over-
> specifying legacy has inherent costs, not only opportunity costs: it
> can lead to de-jure constraints on future evolution that do not exist,
> or are not very strongly felt by most developers, at any rate, on the
> web. Those de-jure constraints can then beget dependent content.
>
As far as I can tell, one of the big costs we (in the same sense of  
"people reading this and their colleagues") have is reverse  
engineering underspecified behaviors that turn out to have significant  
compatibility requirements. This directly cuts down on the amount of  
time that we can spend improving the various implementations in other  
ways. Also if the compatibility requirements impose a design  
constraint that was not evident from the specification it may force  
costly re-architecture. It seems to me that getting all the hard  
requirements out in the open would seem likely to lower the overall  
cost of development.

Received on Tuesday, 17 November 2009 22:50:07 UTC