Hi,
> 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? > > because it will throw an exception if the key does not exist... > Don't you need to coordinate with other developers to know what any > other value returned from get() means? fair point... although it would be better if this was obvious from the spec. > > Do you have the same problem with foo.bar as outlined in my previous > email? If not, why not? > did I miss that email? not sure what this is about. > > 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. > This is the best argument against this so far... > > 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. I thought edge cases are precisely what a specification is supposed to deal with. Anyway, although I don't agree with the other reasons, I find the array case compelling. So lets ignore the proposal to disallow storing undefined. Perhaps you could add a boolean method "exists(key)" to IDBObjectStore to make it easier to tell the two apart. Cheers, Keean.