- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 7 Nov 2012 11:03:07 -0800
- To: Joshua Bell <jsbell@chromium.org>
- Cc: public-webapps <public-webapps@w3.org>
On Wed, Nov 7, 2012 at 10:53 AM, Joshua Bell <jsbell@chromium.org> wrote: > Various atttributes in IndexedDB signal "no value" with |undefined|: > > IDBKeyRange.lowerBound (if not set) > IDBKeyRange.upperBound (if not set) > IDBRequest.result (on error, or on successful deleteDatabase/get with no > value/delete/clear) > IDBCursor.key (if no found record) > IDBCursor.primaryKey (if no found record) > IDBCursorWithValue.value (if no found record) > > It's been pointed out that most Web platform specs use |null| rather than > |undefined| for signaling these states. I seem to recall a push in the > direction of using |undefined| rather than |null| in the IndexedDB spec bit > over a year ago, but my bugzilla-fu was weak. Can anyone discuss or justify > this deviation from the norm? > > (I feel like there's been a trend over the past few years in embrace > ECMAScript's |undefined| value rather than trying to pretend it doesn't > exist, but that may be my imagination. IDB's use of |undefined| didn't > strike me as unusual until it was pointed out.) I tried to push for using undefined in a CSSOM API recently (and getting WebIDL updated to match), but figured it wasn't worth breaking with tradition and dropped it. I think you're right that null should be used for these things. (Luckily, null and undefined are == with each other.) ~TJ
Received on Wednesday, 7 November 2012 19:03:54 UTC