- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 4 May 2011 09:36:37 +0530
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Received on Wednesday, 4 May 2011 04:07:24 UTC
Undefined is also the return value for void functions. The result is essentially the return value of our async methods. And in most cases, the behavior of each async method is just a transformation of the sync method and vice versa. So my thinking is that it should stay as it is. J On Mon, May 2, 2011 at 11:22 PM, Israel Hilerio <israelh@microsoft.com>wrote: > After calling the clear() method on IDBObjectStore, the result of the > IDBRequest is set to undefined according to the "steps for clearing an > object store". > > However, the result property in IDBRequest says that the result value is > undefined when the request results in an error: "This is undefined when the > request resulted in an error." > > In IE, we've been using undefined to signal properties that are not > available to developers and null to signal unassigned values. It seems that > null would be a better result value when the object store has been cleared. > > This would follow the same pattern we use in the deleteDatabase method > where we return a null value for the result of the IDBRequest: "If the steps > above are successful, the implementation must set the result of the request > to null and fire a success event at the request." > > What do you think? > > Israel > >
Received on Wednesday, 4 May 2011 04:07:24 UTC