Re: DOM collections index out of bounds and JavaScript.

On 10/18/10, Boris Zbarsky <> wrote:
> On 10/18/10 9:34 PM, Garrett Smith wrote:
>> \.item\(\d+\s*\)\s*===\s*null lang:javascript
> Doesn't catch cases when the argument to item is not a numeric constant,
> most simply.
Or a reference like `i`, ``, `f["d"]`, `f[ d ]`

\.item\((("|')?\s*(\d+("|')?)|([$_a-z]+)\s*)\)\s*===\s*null lang:javascript

That covers quoted numbers like `"2"` and `'3'` and lexical
environment references. It does not cover object environment
references such as `.item([ 'bing' ] )`.

Regexes seem to be case-insensitive in google code search.\.item\%28%28%28%22|%27%29%3F\s*%28\d%2B%28%22|%27%29%3F%29|%28[%24_a-z]%2B%29\s*%29\%29\s*%3D%3D%3D\s*null+lang%3Ajavascript&sbtn=Search

So I pick up 1 dude's unit test, "test.dom.css.js" that has a
one-liner that makes two assertions (which itself is stupid, but
that's beside the point). I see public code using item( n ) === null
being one file. Seems to be low impact, wouldn't you agree?

The impact to making `item( n )` return `undefined` instead of `null`
when `n` is not found seems pretty minimal.

The benefit is that square bracket property access and the `item`
method have the same result (behavior that was guaranteed in DOM 1)
and that property access does not need to use a proxy to conform to
the spec.


Received on Tuesday, 19 October 2010 16:47:10 UTC