- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 11 Nov 2010 13:06:12 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Keean Schupke <keean@fry-it.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Webapps WG <public-webapps@w3.org>
On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow <jorlow@chromium.org> wrote: > The email I responded to: "It would make sense if you make setting a key to > undefined semantically equivalent to deleting the value (and no error if it > does not exist), and return undefined on a get when no such key exists. That > way 'undefined' cannot exist as a value in the object store, and is a safe > marker for the key not existing in that index." > undefined should be symmetric. If something not existing returns undefined > then passing in undefined should make it not exist. Overloading the meaning > of a get returning undefined is ugly. And simply disallowing a value also > seems a bit odd. But I think this is pretty elegant semantically. As I've asked previously in the tread. What problem are you trying to solve? Can you describe the type of application that gets easier to write/possible to write/has cleaner code/runs faster if we make this change? It seems like deleting on .put(undefined) creates a very unexpected behavior just to try to cover a rare edge case, wanting to both store undefined, and tell it apart from the lack of value. In fact, the proposal doesn't even solve that edge case since it no longer is possible to store undefined. Which brings me back to the question above of what problem you are trying to solve. / Jonas
Received on Thursday, 11 November 2010 21:07:06 UTC