[whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
Before the move to structured clones one could tell if a key was set by calling getItem() and seeing if it returned null (had to use === as someone could have called setItem() w/ null, but that would be coerced to a string for storage). But with the latest draft's switch to structured clones that test no longer clearly differentiates between whether the value returned by getItem() signifies that the key was not set, or the key was set with the value null. As written right now the only way to detect if a key was truly set is to iterate through all of them with 'length' and key(). Perhaps a contains() function that returns true/false based on whether the key is set is warranted? Otherwise you could do something like Python's get() method on dicts where an optional second argument is provided to getItem() which is returned only if the key is not set, allowing a user-provided object represent a key not existing w/ ===. And since I just subscribed to the mailing list, I was wondering if the whole workers/localStorage discussion ended or not, as I can provide a (potentially minor) real-world use-case for sharing access between the page and worker if people want to hear it (in a new email of course). -Brett
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, Sep 23, 2009 at 1:19 PM, Brett Cannon br...@python.org wrote: Before the move to structured clones one could tell if a key was set by calling getItem() and seeing if it returned null (had to use === as someone could have called setItem() w/ null, but that would be coerced to a string for storage). But with the latest draft's switch to structured clones that test no longer clearly differentiates between whether the value returned by getItem() signifies that the key was not set, or the key was set with the value null. As written right now the only way to detect if a key was truly set is to iterate through all of them with 'length' and key(). Perhaps a contains() function that returns true/false based on whether the key is set is warranted? Otherwise you could do something like Python's get() method on dicts where an optional second argument is provided to getItem() which is returned only if the key is not set, allowing a user-provided object represent a key not existing w/ ===. And since I just subscribed to the mailing list, I was wondering if the whole workers/localStorage discussion ended or not, as I can provide a (potentially minor) real-world use-case for sharing access between the page and worker if people want to hear it (in a new email of course). The second method (optional second argument) is definitely the correct one. Common Lisp deals with similar issues by *returning* a second value which is a boolean reflecting whether the key was in the hash (and was simply set to the default value) or was missing (and thus the default value was returned). However, multiple return values isn't a pattern used by most languages, so a second argument that switches the function into returning the was-it-there bool is correct. ~TJ
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, Sep 23, 2009 at 11:30 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Sep 23, 2009 at 1:19 PM, Brett Cannon br...@python.org wrote: Before the move to structured clones one could tell if a key was set by calling getItem() and seeing if it returned null (had to use === as someone could have called setItem() w/ null, but that would be coerced to a string for storage). But with the latest draft's switch to structured clones that test no longer clearly differentiates between whether the value returned by getItem() signifies that the key was not set, or the key was set with the value null. As written right now the only way to detect if a key was truly set is to iterate through all of them with 'length' and key(). Perhaps a contains() function that returns true/false based on whether the key is set is warranted? Otherwise you could do something like Python's get() method on dicts where an optional second argument is provided to getItem() which is returned only if the key is not set, allowing a user-provided object represent a key not existing w/ ===. And since I just subscribed to the mailing list, I was wondering if the whole workers/localStorage discussion ended or not, as I can provide a (potentially minor) real-world use-case for sharing access between the page and worker if people want to hear it (in a new email of course). The second method (optional second argument) is definitely the correct one. Common Lisp deals with similar issues by *returning* a second value which is a boolean reflecting whether the key was in the hash (and was simply set to the default value) or was missing (and thus the default value was returned). However, multiple return values isn't a pattern used by most languages, so a second argument that switches the function into returning the was-it-there bool is correct. I would say it's far from definitely the correct method. I can see use cases where both the default case and a containsItem() function would be useful. Why not add both?
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, 23 Sep 2009 20:19:43 +0200, Brett Cannon br...@python.org wrote: Before the move to structured clones one could tell if a key was set by calling getItem() and seeing if it returned null (had to use === as someone could have called setItem() w/ null, but that would be coerced to a string for storage). But with the latest draft's switch to structured clones that test no longer clearly differentiates between whether the value returned by getItem() signifies that the key was not set, or the key was set with the value null. As written right now the only way to detect if a key was truly set is to iterate through all of them with 'length' and key(). Perhaps a contains() function that returns true/false based on whether the key is set is warranted? Otherwise you could do something like Python's get() method on dicts where an optional second argument is provided to getItem() which is returned only if the key is not set, allowing a user-provided object represent a key not existing w/ ===. Yes, there is ambiguity in getItem() between the case of non existent key or the case or null key. But does storing null keys adds any value, or relevant information ? The User Agent could optimize by treating a setItem(key, null) as a removeItem() because getItem() would return in both cases null, and it would be an opportunity to spend less quota of the storage area. The only side effect of such optimization would be that setItem(key, null) would not produce a new key entry that could be read by key(index). But back on the original issue, doing a setItem(key,null) is just redundant overhead that does not had any information, so the spec could just allow the harmless ambiguity to happen. I personally would prefer setItem(key,null/undefined) to be treated as removeItem(key).
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, Sep 23, 2009 at 1:31 PM, João Eiras jo...@opera.com wrote: On Wed, 23 Sep 2009 20:19:43 +0200, Brett Cannon br...@python.org wrote: Before the move to structured clones one could tell if a key was set by calling getItem() and seeing if it returned null (had to use === as someone could have called setItem() w/ null, but that would be coerced to a string for storage). But with the latest draft's switch to structured clones that test no longer clearly differentiates between whether the value returned by getItem() signifies that the key was not set, or the key was set with the value null. As written right now the only way to detect if a key was truly set is to iterate through all of them with 'length' and key(). Perhaps a contains() function that returns true/false based on whether the key is set is warranted? Otherwise you could do something like Python's get() method on dicts where an optional second argument is provided to getItem() which is returned only if the key is not set, allowing a user-provided object represent a key not existing w/ ===. Yes, there is ambiguity in getItem() between the case of non existent key or the case or null key. But does storing null keys adds any value, or relevant information ? The User Agent could optimize by treating a setItem(key, null) as a removeItem() because getItem() would return in both cases null, and it would be an opportunity to spend less quota of the storage area. The only side effect of such optimization would be that setItem(key, null) would not produce a new key entry that could be read by key(index). But back on the original issue, doing a setItem(key,null) is just redundant overhead that does not had any information, so the spec could just allow the harmless ambiguity to happen. I personally would prefer setItem(key,null/undefined) to be treated as removeItem(key). IIRC, this is how it used to be. If so, does anyone remember why this was changed? Also, what about undefined? It seems kind of weird that we'd let someone store undefined and not null.
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
What are the arguments against adding a containsKey method? This would map consistently to the in operator and hasOwnProperty in ES5. object.containsKey(name) would be mapped to [[GetOwnProperty]](object, name) !== undefined in ES5 meta language. That seems most consistent to existing APIs. On Wed, Sep 23, 2009 at 13:40, Jeremy Orlow jor...@chromium.org wrote: On Wed, Sep 23, 2009 at 1:31 PM, João Eiras jo...@opera.com wrote: On Wed, 23 Sep 2009 20:19:43 +0200, Brett Cannon br...@python.org wrote: Before the move to structured clones one could tell if a key was set by calling getItem() and seeing if it returned null (had to use === as someone could have called setItem() w/ null, but that would be coerced to a string for storage). But with the latest draft's switch to structured clones that test no longer clearly differentiates between whether the value returned by getItem() signifies that the key was not set, or the key was set with the value null. As written right now the only way to detect if a key was truly set is to iterate through all of them with 'length' and key(). Perhaps a contains() function that returns true/false based on whether the key is set is warranted? Otherwise you could do something like Python's get() method on dicts where an optional second argument is provided to getItem() which is returned only if the key is not set, allowing a user-provided object represent a key not existing w/ ===. Yes, there is ambiguity in getItem() between the case of non existent key or the case or null key. But does storing null keys adds any value, or relevant information ? The User Agent could optimize by treating a setItem(key, null) as a removeItem() because getItem() would return in both cases null, and it would be an opportunity to spend less quota of the storage area. The only side effect of such optimization would be that setItem(key, null) would not produce a new key entry that could be read by key(index). But back on the original issue, doing a setItem(key,null) is just redundant overhead that does not had any information, so the spec could just allow the harmless ambiguity to happen. I personally would prefer setItem(key,null/undefined) to be treated as removeItem(key). IIRC, this is how it used to be. If so, does anyone remember why this was changed? Also, what about undefined? It seems kind of weird that we'd let someone store undefined and not null. -- erik
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, 23 Sep 2009 23:03:38 +0200, Erik Arvidsson erik.arvids...@gmail.com wrote: What are the arguments against adding a containsKey method? This would map consistently to the in operator and hasOwnProperty in ES5. object.containsKey(name) would be mapped to [[GetOwnProperty]](object, name) !== undefined in ES5 meta language. That seems most consistent to existing APIs. A containsKey or hasItem, preferably, would still not address the ambiguity issue.
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, Sep 23, 2009 at 14:28, João Eiras jo...@opera.com wrote: On Wed, 23 Sep 2009 23:03:38 +0200, Erik Arvidsson erik.arvids...@gmail.com wrote: What are the arguments against adding a containsKey method? This would map consistently to the in operator and hasOwnProperty in ES5. object.containsKey(name) would be mapped to [[GetOwnProperty]](object, name) !== undefined in ES5 meta language. That seems most consistent to existing APIs. A containsKey or hasItem, preferably, would still not address the ambiguity issue. ES and most other languages that do not throw when you try to get a non existing item out of a collection will have this problem. If they return a value, getItem will never be able to tell if that value was due to an absent item or not. The only way to make getItem handle this is to either throw or return two values. Both are not very consistent with other web apis. -- erik
Re: [whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()
On Wed, Sep 23, 2009 at 14:28, João Eiras jo...@opera.com wrote: On Wed, 23 Sep 2009 23:03:38 +0200, Erik Arvidsson erik.arvids...@gmail.com wrote: What are the arguments against adding a containsKey method? This would map consistently to the in operator and hasOwnProperty in ES5. object.containsKey(name) would be mapped to [[GetOwnProperty]](object, name) !== undefined in ES5 meta language. That seems most consistent to existing APIs. A containsKey or hasItem, preferably, would still not address the ambiguity issue. It doesn't remove it, but it helps deal with it. You could use hasItem()/containsKey()/whatever() in cases where you did receive null from getItem() and you care if the key was actually set or not. Otherwise the only other good solution is adding a singleton to the Storage interface which getItem() returns when the key is not set. Disallowing using 'undefined' or null as a value suddenly as a special case just for Storage.setItem() when it comes to working with structured clones. But if people really want to go down that route I would swap from null to undefined to better match JS semantics of representing when something doesn't exist. -Brett
