On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow jor...@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
Yes, I prefer it due to the symmetry, and agree that its a judgment call. I
guess the advantage of allowing it is library's can disallow if they like.
The reverse is not true, if you disallow it a library cannot allow it.
Cheers,
Keean
On 12 Nov 2010 09:00, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Nov 12, 2010 at 12:59 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow jor...@chromium.org
wrote:
The email I responded to: It would make sense if you make setting a key
I really like this idea. I only skimmed the arguments against it, but they
all seemed pretty hand-wavy to me.
J
On Mon, Nov 8, 2010 at 9:06 PM, Keean Schupke ke...@fry-it.com wrote:
It would make sense if you make setting a key to undefined semantically
equivalent to deleting the value (and
On Thu, Nov 11, 2010 at 4:26 AM, Jeremy Orlow jor...@chromium.org wrote:
I really like this idea. I only skimmed the arguments against it, but they
all seemed pretty hand-wavy to me.
Which idea specifically do you like?
/ Jonas
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
On 11/11/2010 11:44 AM, Jeremy Orlow 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
On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow jor...@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
Hi All,
One of the things we discussed at TPAC was the fact that
IDBObjectStore.get() and IDBObjectStore.delete() currently fire an
error event if no record with the supplied key exists.
Especially for .delete() this seems suboptimal as the author wanted
the entry with the given key removed
On Mon, Nov 8, 2010 at 8:24 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
One of the things we discussed at TPAC was the fact that
IDBObjectStore.get() and IDBObjectStore.delete() currently fire an
error event if no record with the supplied key exists.
Especially for .delete() this
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
On Mon, Nov 8, 2010 at 10:06 AM, Keean Schupke ke...@fry-it.com wrote:
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'
Hi,
In code, if:
idbObjectStoreSync.put(key, undefined) does the same as
idbObjectStoreSync.remove(key)
then
idbObjectStoreSync.get(key) can safely return undefined for no such key
exists.
Consider:
idbObjectStoreSync.put('mykey', undefined); // deletes the object stored
under mykey or
Obviously I need to the key and value the correct way around for 'put'...
Cheers,
Keean.
On 8 November 2010 18:41, Keean Schupke ke...@fry-it.com wrote:
Hi,
In code, if:
idbObjectStoreSync.put(key, undefined) does the same as
idbObjectStoreSync.remove(key)
then
On Mon, Nov 8, 2010 at 10:41 AM, Keean Schupke ke...@fry-it.com wrote:
Hi,
In code, if:
idbObjectStoreSync.put(key, undefined) does the same as
idbObjectStoreSync.remove(key)
then
idbObjectStoreSync.get(key) can safely return undefined for no such key
exists.
Consider:
Hi,
Indeed. But I think this is more unexpected and confusing than having
.get() return the same thing if the entry exists as if it contains
undefined.
/ Jonas
I don't understand that.
with the proposal, undefined clearly means the entry does not exist as there
is no way to put an
I was only suggesting this as it makes the operations symmetrical in the
sense that if get returns undefined for key does not exist,
put(undefined, key) should mean make this key not exist, in a declarative
sense.
For me this is clearer than the alternatives (which may require exceptions
to deal
On Monday, November 8, 2010, Keean Schupke ke...@fry-it.com wrote:
Hi,
Indeed. But I think this is more unexpected and confusing than having
.get() return the same thing if the entry exists as if it contains
undefined.
/ Jonas
I don't understand that.
with the proposal, undefined clearly
Hi,
I don't understand that.
with the proposal, undefined clearly means the entry does not exist as
there is no way to put an undefined into the object store (as
.put(undefined, key) deletes the entry).
The confusing part is that a function called 'put' actually deletes
something,
On Mon, Nov 8, 2010 at 12:02 PM, Keean Schupke ke...@fry-it.com wrote:
Hi,
I don't understand that.
with the proposal, undefined clearly means the entry does not exist as
there is no way to put an undefined into the object store (as
.put(undefined, key) deletes the entry).
The
What is the use case for storing undefined in an object-store?
Cheers,
Keean.
On 8 November 2010 20:59, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 12:02 PM, Keean Schupke ke...@fry-it.com wrote:
Hi,
I don't understand that.
with the proposal, undefined clearly
Let me put it another way. Why do you want to allow putting 'undefined' into
the object store? All that does is make the API for get ambiguous. What does
it gain you? Why do you want to make 'get' ambiguous?
I think having an unambiguous API for 'get' is worth more than being able to
'put'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1 from me. The purpose of undefined in JavaScript is to represent the
value of a non-existent key, it fits perfectly with get() for a key
that doesn't exist. This is exactly how property access works with
JavaScript objects, so it is consistent and
On Mon, Nov 8, 2010 at 3:18 PM, Keean Schupke ke...@fry-it.com wrote:
Let me put it another way. Why do you want to allow putting 'undefined' into
the object store? All that does is make the API for get ambiguous. What does
it gain you? Why do you want to make 'get' ambiguous?
It seems like a
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you are looking for ways to shoot yourself in the foot, why not
just do:
undefined = true;
Storing undefined is not an important use case, practical usage is far
more important than optimizing for edge cases just because you can
think of them.
On Mon, Nov 8, 2010 at 3:33 PM, Keean Schupke ke...@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
On Mon, Nov 8, 2010 at 4:04 PM, Keean Schupke ke...@fry-it.com wrote:
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...
That is no longer
Sounds good to me...
Cheers,
Keean.
On 9 November 2010 00:16, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 8, 2010 at 4:04 PM, Keean Schupke ke...@fry-it.com wrote:
Hi,
Why do you want to check that a key exists before you delete it? Why
not just call delete(key) always and
On Mon, Nov 8, 2010 at 4:16 PM, Jonas Sicking jo...@sicking.cc wrote:
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
30 matches
Mail list logo
