- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Tue, 19 Oct 2010 09:46:33 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps@w3.org
On 10/18/10, Boris Zbarsky <bzbarsky@mit.edu> 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`, `foo.bar`, `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( foo.bar.baz[ 'bing' ] )`.
Regexes seem to be case-insensitive in google code search.
http://www.google.com/codesearch?hl=en&lr=&q=\.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.
Garrett
Received on Tuesday, 19 October 2010 16:47:10 UTC