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

Re: IndexedDB: undefined parameters

From: Joshua Bell <jsbell@chromium.org>
Date: Wed, 10 Oct 2012 16:11:50 -0700
Message-ID: <CAD649j7Pc5+=9w0e1nZKK+ZJtoy6UDczZoEzwP51mNrXG5irEg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Odin HÝrthe Omdal <odinho@opera.com>, public-webapps@w3.org
On Wed, Oct 10, 2012 at 3:58 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Oct 10, 2012 at 11:15 AM, Odin HÝrthe Omdal <odinho@opera.com>
> wrote:
> > Last time I looked at it, WebIDL said [TreatUndefinedAs=Missing] is
> meant to
> > be for legacy API's, and not new ones. I think that a bit strange and
> > counter productive. Why?
> [TreatUndefinedAs] is only intended for arguments that take DOMString
> or DOMString?.
> http://dev.w3.org/2006/webapi/WebIDL/#TreatUndefinedAs

I think we're confused by the following text at the above link (a couple
paragraphs down), which contrasts with the first use case (DOMString):

The second use for [TreatUndefinedAs] is to control how undefined values
> passed to a function corresponding to an operation are treated. If it is
> specified as[TreatUndefinedAs=Missing] on an optional operation argument,
> then an explicit undefined value will cause the function call to be treated
> as if the argument had been omitted.

If this behavior should indeed be the default to match ES6 semantics (which
I think practically everyone on this thread agrees is a Good Thing), then
the above paragraph is redundant and the overload resolution algorithm step
4 can be simplified.
Received on Wednesday, 10 October 2012 23:12:18 UTC

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