- From: Brett Cannon <brett@python.org>
- Date: Wed, 23 Sep 2009 14:38:25 -0700
On Wed, Sep 23, 2009 at 14:28, Jo?o Eiras <joaoe at opera.com> wrote: > On Wed, 23 Sep 2009 23:03:38 +0200, Erik Arvidsson > <erik.arvidsson at 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
Received on Wednesday, 23 September 2009 14:38:25 UTC