Re: [Web Storage] A couple questions about the storage spec

On 2010/8/17, at 上午4:39, Jeremy Orlow wrote:

> On Tue, Aug 17, 2010 at 12:08 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 8 Jul 2010, David John Burrowes wrote:
> >
> > I have a couple questions about the storage spec (I'm reading the June
> > 15th version at (http://dev.w3.org/html5/webstorage/).
> >
> > (1) The spec says: "The object's indices of the supported indexed
> > properties are the numbers in the range zero to one less than the number
> > of key/value pairs currently present in the list associated with the
> > object. If the list is empty, then there are no supported indexed
> > properties."
> >
> > As far as I can tell, this seems to say I should be able to say
> > something like:
> >       window.localStorage[3]
> > and get something back (not clear if the key or the value).  Am I right
> > in my interpretation of that paragraph?
> 
> Yes.
> 
> 
> > I saw some discussion earlier about whether something like
> > localStorage[3] was meaningful, but I didn't find the resolution.  It
> > does seem undesirable/confusing to me.  And none of the browsers I've
> > tried this with do this.
> 
> On Wed, 14 Jul 2010, Jeremy Orlow wrote:
> >
> > All the browsers I know of handle localStorage[3] as
> > localStorage.get/setItem('3', ...).  My impression is that this behavior
> > is pretty firmly rooted at this point.  It seems as though the spec may
> > need to change.
> 
> Firefox seems to implement this correctly. It just seems to be a bug in
> Opera and Chrome. (I didn't test Safari or IE.)

I'm surprised I overlooked Firefox.
I think in the grand scheme of things here, this is a minor point.  But, in Firefox saying localStorage[2] = "foo" creates a key (2) with a value (foo). Shouldn't that be changing the name of the 2nd key?  Otherwise this notation is a bit asymmetrical (does one thing when read from, a very different thing when assigned to).

> Safari and IE act the same way as Opera and Chrome, so I would agree with David's assertion that this behavior is fairly firmly rooted.  But you disagree, Ian?  If so, let me just make sure I understand correctly: if you do localStorage[x] and x is a number, then it should be an index into item number x, and if x is anything else, it should be interpreted as .get(x)/.set(x, ...) ?

I algo agree that it would be nice for the correct behavior for this ambiguous situation to be explicitly stated in the spec.


> This is the kind of thing that will shake out when we have a test suite.

I'm sure that is true!


> On Thu, 8 Jul 2010, David John Burrowes wrote:
> >
> > (2) The spec also says:
> > "The names of the supported named properties on a Storage object are the
> > keys of each key/value pair currently present in the list associated
> > with the object."
> > I read that (possibly/probably wrongly) as saying I should be able to say
> >       window.localStorage.setItem("foo", "bar");
> >       myVariable = window.localStorage["foo"];
> > and now myVariable will have "bar".
> 
> Yes.
> 
> 
> > If my reading is right (and it is the behavior I see in a couple browsers) this makes me very nervous, because I can do something like:
> >       window.localStorage.setItem("length", "a value we computer");
> >       window.localStorage.setItem("clear", "something that is transparent");
> > which of course allows:
> >       window.localStorage["length"];
> >       window.localStorage["clear"];
> > but in the browsers I've looked at, this (of course) also kinda messes up things like:
> >       for (index = 0; index < window.localStorage.length; index++) {
> >               // whatever
> >       }
> >       window.localStorage.clear();
> > since length is now not a number, and clear isn't a function.
> 
> Actually length and clear don't get overrideen, because the interface is
> not defined as [OverrideBuiltins].

So, that means window.localStorage["length"] will still return "a value we computer"[sic] ?

> 
> Wha?  This seems completely different than your answer in this thread: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020349.html
>  
> 
> > Why is this a desirable feature?
> 
> Code like this:
> 
>   if (localStorage.visitedAlready) { ... }
> 
> ...is simpler to read than code like:
> 
>   if (localStorage.getItem('visitedAlready')) { ... }

I can definitely see that that is easier to read.  It also strikes me as fragile to write this as localStorage.visitedAlready.  If a later version of the standard adds a 'visitedAlready' function or attribute to the localStorage object, my code may not behave as it did in the previous version (which scares the ____ out of me as a developer :-) ).  But, this looks like it depends on the previous part of my question about whether length and clear get overridden.  


> > (3) Real nitpicking here:
> > The IDL for the Storage interface says
> >   setter creator void setItem(in DOMString key, in any data);
> > but the text says
> >       The setItem(key, value) method
> > Note the name of the second parameter is different between these.
> 
> Fixed IDL.

Thanks!  My type-A-ness is made happy ;-)


David


> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>