Re: Conflicts between W3C specs and ES5?

Catching up, my Inbox was scrambled...

On Nov 17, 2009, at 7:54 AM, James Graham wrote:

> 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?
>
> Oversight. It would be good if someone who knows the details could  
> add it (with justification about why it is evil and any data you  
> have about how pervasive it is, if you like).

Google codesearch is useful and it is making me eat my words. Some of  
this is recent:

http://www.google.com/codesearch?hl=en&lr=&q=%22.arguments%5B%22+lang%3Ajavascript&sbtn=Search

Ignore the window.arguments Mozilla uses, those are not Arguments  
objects, just arrays we give to dialog and other "opened" windows. I  
did not see an obvious way to exclude the mozilla/... hits from the  
codesearch results.

The bad news is that it seems YUI has grown some reflection code that  
uses (for active function this.getEvent) this.getEvent.caller.arguments.

 From adapter/ext/ext-base.js it seems this may have been copied into  
(something called; perhaps not the canonical) ext.js.

But these aren't the only hits.

Whether or not Google could have evangelized or paid to eliminate some  
of the foo.arguments uses out there, we seem to be stuck with  
supporting foo.arguments, and it seems to propagating still -- for the  
very foo.caller.arguments[i] stack inspection reason that drives some  
security-minded TC39 members bonkers!

It is specificiable, we implement it with little code. We also do  
mandatory access control checks to stop XSS attacks via foo.caller.  
I'll stop here and let other TC39'ers react.


>> Date.parse we've discussed. Non-interoperable mess in detail, many  
>> corner cases (IE seems to apply heuristics, not sure whether locale- 
>> specific, to mm/dd vs. dd/mm month-day order, for example).
>> Date.UTC. I agree that's a small issue, easy to spec -- a bug on  
>> ES5 if you will. Too bad it wasn't reported (AFAIK).
>
> Is this enough to be considered a bug report for ES6? Or does es- 
> discuss have to be involved?

http://bugs.ecmascript.org/ -- mail me if you want access.

/be