Re: IndexedDB: undefined parameters

On Wed, Oct 10, 2012 at 4:10 PM, Joshua Bell <jsbell@google.com> wrote:
> 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.
>
>
> To match ES6 semantics (which I think 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?).

Indeed. I had read that as only applying to DOMString arguments, but
on rereading I agree that that's probably not the right
interpretation.

So yes, I think the WebIDL spec is out-of-date here. I can't actually
find where it defines that undefined is treated as "was not passed".
I'm not sure if this is an oversight or if this isn't agreed upon
behavior. I was under the impression that it was, but I could be
wrong.

/ Jonas

Received on Wednesday, 10 October 2012 23:35:42 UTC