- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 8 Nov 2010 15:49:55 -0800
- To: Keean Schupke <keean@fry-it.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>
On Mon, Nov 8, 2010 at 3:33 PM, Keean Schupke <keean@fry-it.com> wrote:
> If more than one developer are working on a project, there is no way I can
> know if the other developer has put 'undefined' objects into the store
> (unless the specification enforces it).
> So every time I am checking if a key exists (maybe to delete the key) I need
> to check if it _really_ exists, or else I can run into problems. For
> example:
> In module A:
> put(undefined, key);
> In module B:
> if (get(key) !== undefined) {
> remove(key);
> }
> So the object store will fill up with "key = undefined" until we run out of
> memory.
Why do you want to check that a key exists before you delete it? Why
not just call delete(key) always and rest assured that it's gone?
Don't you need to coordinate with other developers to know what any
other value returned from get() means?
Do you have the same problem with foo.bar as outlined in my previous
email? If not, why not?
For what it's worth, I do agree that it isn't ideal that .get() can't
tell the two apart. However I think that forbidding storing undefined
is a worse solution which just moves the problem from one place to
another. Consider code that does:
for (i = 0; i < myArray.length; ++i) {
objectStore.put(myArray[i]);
}
and then creating a cursor which iterates over all stored values. This
code would be buggy since it doesn't deal with 'undefined' being
stored in the array.
Similar to Kris, I think worrying about 'undefined' is worrying about
an edge case. Simplicity is better than trying to cove every possible
edge case.
/ Jonas
Received on Monday, 8 November 2010 23:50:49 UTC