Re: IndexedDB: undefined parameters

On Oct 11, 2012 5:51 PM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote:
>
> On 10/11/12 8:43 PM, Jonas Sicking wrote:
>>
>> Even for an API like:
>>
>> void bar(optional int x);
>> void bar(MyInterface? x);
>>
>> with or without the "treat undefined as not-passed" rule, it's
>> definitely not obvious which one
>>
>> bar(undefined);
>>
>> would call. I think the WebIDL spec unambiguously makes it match the
>> second one, but I wouldn't call that obvious to authors.
>
>
> It's the second one as written.  If the int arg there were
[TreatUndefinedAs=Missing], then the first overload would be chosen, as
WebIDL is written today.  And if we made undefined default to missing, it
would presumably be the first one in this example.

I think that whatever we choose to do here, patterns like the ones in your
or my example aren't going to be obvious to web authors.

Which is why I think we should discourage them in prose or in rules in
WebIDL.

>> In general, WebIDL is ultimately a spec aimed at spec authors, not at
>> developers. We have to make spec authors assume some level of
>> responsibility for the APIs that they create.
>
>
> I'm not that sanguine about it so far, but maybe that's because most spec
authors so far don't really understand WebIDL very well...

I somewhat agree, but I don't think that anything we do here is going to
have a big effect on what spec authors do.

>>> If so, all we're really saying is that overload resolution will drop
>>> _trailing_ undefined from the argc before determining the overload to
use,
>>> right?
>>
>>
>> If we go with option B above, then doing that sounds good yes.
>
>
> I can live with that.

For what it's worth, I'm fine with either function getting selected from
your original example.

/ Jonas

Received on Friday, 12 October 2012 07:30:07 UTC