W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [IndexedDB] Attributes with undefined vs. null

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 7 Nov 2012 11:03:07 -0800
Message-ID: <CAAWBYDAfk-dTnp3GGYQ69dgBdg5e4gevB4byQ8nF0A2FjtnWeg@mail.gmail.com>
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.)

Received on Wednesday, 7 November 2012 19:03:54 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:50 UTC