- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 10 Oct 2012 16:34:45 -0700
- To: Joshua Bell <jsbell@google.com>
- Cc: Odin Hørthe Omdal <odinho@opera.com>, public-webapps@w3.org
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