Comments on localStorage

In the second example: "localStorage.pageLoadCount = 
parseInt(localStorage.pageLoadCount, 10) + 1;". I think it would be 
helpful to add a comment like "// localStorage values are always 
strings, so they should be explicitly converted to integers if they will 
be used numerically" to tell people what the parseInt is for, since it's 
a fairly non-obvious feature of JS.

Why use parseInt(..., 10) instead of just parseInt(...) (which defaults 
to decimal (unless the string begins with "0x"))?

(It's easier to write "localStorage.pageLoadCount = 
+localStorage.pageLoadCount + 1;", which works because "The unary + 
operator converts its operand to Number type". But that's much less 
obvious to the casual reader, so parseInt is probably sensible.)


For key(n): "If n is less than zero ... then this method must raise an 
INDEX_SIZE_ERR exception" - how can it be less than zero, when the IDL 
says it's an unsigned long?

"When the localStorage attribute is accessed, the user agent must check 
to see if it has allocated local storage area for the for the origin of 
the active document of the browsing context of the Window object on 
which the method was invoked." - s/allocated local/allocated a local/, 
s/for the for the/for the/

"When the localStorage attribute is accessed, ... The user agent must 
then create a Storage object associated with that origin's local storage 
area, and return it." - that's saying it must create a distinct new 
object for every single access to localStorage, which can't be right. 
(If it was right, then phrases like "[the] Window object's localStorage 
attribute's Storage object" wouldn't make sense, because there wouldn't 
be only one Storage object associated with that attribute.)

"the user agent must dispatch an event ... which uses the StorageEvent," 
- should say "the StorageEvent interface"

What should oldValue be if I call removeItem(key) where key is not in 
storage? (There is no old value, but it's not newly added either, so 
this seems unspecified.)

When defining "The storage event": "address of the page" should link to 
a definition of exactly what that means.

When defining StorageEvent: "The url attribute represents the address of 
the document that changed the key." - no it doesn't (I think) - if one 
document changes the localStorage of another document, it's the address 
of the second document.

"The source attribute represents the Window that changed the key." - ditto.

In the Threads section, "Multiple browsing contexts must be able to 
access the local storage areas simultaneously in a predictable manner" 
seems impossible to satisfy, since if two try to access the local 
storage at the same instant then I can't predict which one will get in 
first, hence it's unpredictable (even though that's a perfectly sensible 
way to implement concurrency). It could perhaps be made clearer by just 
stating that concurrent script execution must be serializable with 
respect to localStorage, i.e. the final state of the localStorage object 
must be equivalent to the state after some (any) serial execution of the 
scripts.

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Friday, 17 October 2008 13:10:24 UTC