Ian Hickson wrote: 
On Wed, 29 Apr 2009, John J Barton 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.
    

It's not an array or a pseudo-array. It's an enumerable JS host object.
So why call the property |length|? Wouldn't an enumerable JS host object be just as fabulous with getNumberOfItems()?

But the part that has me confused is maybe just me being dumb.  I just have a hard time with:
   sessionStorage[2] = "foo";  // set the key |2| to value "foo".
then
  var x = sessionStorage[2];  // null? "foo"? 
  var y = sessionStorage[0]; // "2"
I'm thinking: why do I have to think so hard about this? It should be just an associative array.

Firefox will have to have special code to implement Storage anyway; why is 
more special code to show it in Firebug a bad thing? In fact, it's 
probably a good thing, since for Storage you probably don't want to be 
showing the data in the debugger all the time anyway (since that has 
performance implications).
Firebug shows objects from Firefox to developers. The appropriate display format for objects depends on the character of the objects and the needs of developers. For example, arrays are shown in square brackets with the first few entries, ["foo", "bar", ...]. HTML Elements are shown with their nodeName and id if any.  In this way developers can quickly get an idea of the nature of the object, and perhaps drill down for more information.

How many display formats should be created? One for every kind of object is simply impractical.  Even if time allowed to create formats for all the built-in types, all the DOM types, all the library types (prototype, jquery, dojo,...) etc, there would still be user types. So you have to create categories of representations that cover the important cases.  Firebug has about thirty.

Now given an object, how do we assign it to one of these thirty representations?  The only possibility is to examine the properties of the object.  Since for sure the Javascript built in Array type has a |length| and since any type with a length property is likely to be designed to be array-like, the tests for representation use the existence of a length property that is a finite number as part of its test.  

Of course there are objects that are not arrays and yet have length, eg Strings. Firebug has a separate representation to avoid ["t", "h", "i", "s"].

Since Storage has a length it was originally appearing in Firebug as [].

If your API was such that sessionStorage[i] gave the i-th entry, a key, value pair, then the array representation would be already working for us.

I hope this makes the issues clearer.
jjb