- From: Oliver Hunt <oliver@apple.com>
- Date: Mon, 18 Oct 2010 18:18:32 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Erik Arvidsson <arv@chromium.org>, public-webapps@w3.org, Anne van Kesteren <annevk@opera.com>
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. --Oliver > > -- > Cameron McCormack ≝ http://mcc.id.au/ >
Received on Tuesday, 19 October 2010 01:19:05 UTC