Re: Storage 'length' and enumeration

John J. Barton Wed, 29 Apr 2009 20:49:39 -0700

Ian Hickson wrote:

On Wed, 29 Apr 2009, John J Barton wrote:

So why call the property |length|? Wouldn't an enumerable JS host object 
be just as fabulous with getNumberOfItems()?


All the other host objects use |length|.

For purposes that I hope are sound.

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.


You only have to think hard about this if you use numeric keys and use the 
implied accessors. Just use .setItem("2") and .getItem("2"), or use a 
non-numeric key, and then there's no confusion.

So why is numeric keys part of the API?

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.


That's no the only possibility by a long shot. In fact it's not even a 
particularly good option; I would recommend using "instanceof" and the 
like instead.

What would you recommend to use for the right hand side of "instanceof"? Recall the goal here is to provide a visual representation of an object, any object in any _javascript_ program what so ever.

Of course there are objects that are not arrays and yet have length, eg 
Strings.


There are lots of objects that are not arrays (or should not be rendered 
as arrays) and yet have length. Collections, TimeRanges, <select> 
elements, Window objects, History, CanvasPixelArrays, etc.

But in the context of Storage API, what do I conclude? That Storage should use length because it is like a TimeRange? As I said before, the mistakes of the past should not be repeated. "Consistency" is an aid to programmers when it helps us quickly write correct code. Adopting length to be consistent makes sense if that will help programmers to quickly write correct Storage code. But in the Storage case a length property would cause confusion and lead to incorrect code. Therefore I argue against its use in the API.

jjb

Re: Storage 'length' and enumeration

Reply via email to