W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Storage 'length' and enumeration

From: John J Barton <johnjbarton@johnjbarton.com>
Date: Wed, 29 Apr 2009 16:10:32 -0700
Message-ID: <49F8DE68.8070803@johnjbarton.com>
To: Anne van Kesteren <annevk@opera.com>
CC: Ian Hickson <ian@hixie.ch>, public-webapps@w3.org
Anne van Kesteren wrote:
> On Wed, 29 Apr 2009 20:51:33 +0200, John J Barton 
> <johnjbarton@johnjbarton.com> wrote:
>> Yes and Firebug has to have special code for HTMLCollection because 
>> this mistake
>> was made in the past. Now we will have to have different special code 
>> for
>> Storage. Rather than modeling new API on old mistakes, consider 
>> learning from the past experience and take a direction that 
>> developers will find less
>> confusing. Pseudo-arrays with "except... this and that" makes APIs 
>> intricate and
>> puzzling. A simpler and less ambiguous approach would be better in my 
>> opinion.
>
> Is there any type of object that holds a collection that does not use 
> .length? Seems a bit weird to break consistency here in my opinion.
Consistency is exactly not wanted, because it creates the impression of 
an array-like access pattern where there is not one.   sessionStorage[2] 
is not the third item stored.   Actually I don't know what it is, I'm 
confused.

There are lots of on-line articles explaining  Javascript arrays versus 
associative arrays (objects). By having a type which is an associative 
array -- Storage -- share a property name with Array just makes matters 
worse.

jjb
Received on Wednesday, 29 April 2009 23:06:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT