On Fri, Nov 12, 2010 at 12:59 AM, Jeremy Orlow wrote:
> On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking wrote:
>>
>> On Thu, Nov 11, 2010 at 11:44 AM, Jeremy Orlow
>> wrote:
>> > The email I responded to: "It would make sense if you make setting a key
>> > to
>> > undefined semantically equivale
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" wrote:
> On Fri, Nov 12,
On Fri, Nov 12, 2010 at 12:06 AM, Jonas Sicking wrote:
> On Thu, Nov 11, 2010 at 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)
On Thu, Nov 11, 2010 at 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 'un
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 e
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 Thu, Nov 11, 2010 at 4:26 AM, Jeremy Orlow 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
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 wrote:
> It would make sense if you make setting a key to undefined semantically
> equivalent to deleting the value (and no error if it
On Mon, Nov 8, 2010 at 4:16 PM, Jonas Sicking 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 deal
Sounds good to me...
Cheers,
Keean.
On 9 November 2010 00:16, Jonas Sicking wrote:
> On Mon, Nov 8, 2010 at 4:04 PM, Keean Schupke 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
On Mon, Nov 8, 2010 at 4:04 PM, Keean Schupke 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 the ca
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
On Mon, Nov 8, 2010 at 3:33 PM, Keean Schupke 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
-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.
Kri
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
+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 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 loose-loose si
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' 'undefi
On Mon, Nov 8, 2010 at 2:39 PM, Keean Schupke wrote:
> The problem I am trying to solve is not knowing if "get(key) === undefined"
> means the key does not exist or there is a key with a value of undefined.
> The solution is to disallow inserting undefined. Now there is no ambiguity,
> if get(key)
The problem I am trying to solve is not knowing if "get(key) === undefined"
means the key does not exist or there is a key with a value of undefined.
The solution is to disallow inserting undefined. Now there is no ambiguity,
if get(key) returns undefined, it _must_ be because the key does not exi
On Mon, Nov 8, 2010 at 1:41 PM, Keean Schupke wrote:
> What is the use case for storing undefined in an object-store?
I don't know. But if that's not the problem you were trying to solve,
then what problem were you trying to solve?
/ Jonas
What is the use case for storing undefined in an object-store?
Cheers,
Keean.
On 8 November 2010 20:59, Jonas Sicking wrote:
> On Mon, Nov 8, 2010 at 12:02 PM, Keean Schupke wrote:
> > Hi,
> >
> >> > I don't understand that.
> >> > with the proposal, undefined clearly means the entry does not
On Mon, Nov 8, 2010 at 12:02 PM, Keean Schupke 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 confusi
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 Monday, November 8, 2010, Keean Schupke 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 means th
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
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 u
On Mon, Nov 8, 2010 at 10:41 AM, Keean Schupke 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:
> idbObjectStoreSync.put(
Obviously I need to the key and value the correct way around for 'put'...
Cheers,
Keean.
On 8 November 2010 18:41, Keean Schupke wrote:
> Hi,
>
> In code, if:
>
> idbObjectStoreSync.put(key, undefined) does the same as
> idbObjectStoreSync.remove(key)
>
> then
>
> idbObjectStoreSync.get(key)
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 noo
On Mon, Nov 8, 2010 at 10:06 AM, Keean Schupke 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'
> cannot exist as a
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
On Mon, Nov 8, 2010 at 8:24 AM, Jonas Sicking 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 seems suboptim
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 anywa
34 matches
Mail list logo
