Re: DOM collections index out of bounds and JavaScript.

On Oct 18, 2010, at 6:18 PM, Oliver Hunt wrote:

> 
> On Oct 18, 2010, at 6:11 PM, Cameron McCormack wrote:
> 
>> Erik Arvidsson:
>>> The problem is that trying to get a non existing property in JS should
>>> return undefined. Not null and not an empty string. I understand that
>>> the spec used null since Java does not have undefined. Since we are
>>> trying to realign these specs with the web it would make sense to try
>>> to make them fit better with JavaScript and mandate that the JS
>>> bindings for collections should return undefined for getting an item
>>> out of bounds.
>> 
>> Does it particularly matter that collection.item(999) returns null while
>> collection['999'] evaluates to undefined?  To me, it makes sense enough.
>> Functions and properties that returns Nodes, and which have no Node to
>> return, return null.  I think for consistency with all of these other
>> funtions and properties, it is preferable to return null from
>> collection.item().  That’s a much bigger (better) consistency to strive
>> for than one between collection.item(999) and collection['999'], IMO.
> 
> There's no difference between collection[999] and collection['999'] as an implementation has to check to see if a string can be converted to an integer (just as it does with array), otherwise for(in) enumeration would not work.
> 
> Also in ecmascript logically all properties are string names it's only for reasons of performance that implementations distinguish integer vs. string property names internally.

Note that Cameron didn't compare collection['999'] and collection[999] (these are indeed identical by definition in JS). Rather, the comparison was between collection['999'] and collection.item(999). Some collection-like objects in the DOM both allow array-like index access and also have an explicit item() method to get the n-th item.

Regards,
Maciej

Received on Tuesday, 19 October 2010 07:53:08 UTC