Re: [Bug 23933] Proposal: Change constraints to use WebIDL dictionaries

I get your point of view. You are comparing this case to object 
inheritance where the API expects you to pass in an object that 
implements function filter() -- and it does -- but it also happens to 
implement function close(). So from your point of view, the API should 
ignore close() and accept the input. In that case, I would agree with 
you. The problem is that we're *not* talking about classes/functions. We 
are talking about *data*.

You are proposing a sort of "data inheritance" and I get that you want 
to avoid throwing exceptions in order to allow new keys to be added in 
the future, but my point remains: you need to either ignore unknown 
keys, or provide a function that checks if a key is supported, but not both.

You can read on below for more specific answers but my main point is above.

On 06/12/2013 1:53 PM, Jan-Ivar Bruaroey wrote:
> On 12/6/13 11:56 AM, cowwoc wrote:
>> There is nothing in Javascript which implies that unknown keys should 
>> be ignored silently.
>
> Yes there is.
>
> JavaScript APIs accept extra parameters and do not throw. This is 
> established practice, as Travis points out in 
> http://lists.w3.org/Archives/Public/public-media-capture/2013Oct/0129.html
>
> There is nothing in Javascript which implies that unknown keys should 
> be ANYTHING BUT ignored silently.

Extra parameters are not the same thing as unknown keys in a dictionary; 
they are varargs of type Object[]. Unknown dictionary keys are 
equivalent to passing an invalid *value* into a known function parameter.

>> Throwing exceptions on bad input is not meant as a mechanism for 
>> detecting browser support. There is no duplication here. Typos are 
>> not an indication that the browser doesn't support the input *yet*. 
>> They are an indication that the browser may *never* support this kind 
>> of input.
>
> You cannot distinguish typos from future parameters in JavaScript, and 
> trying to is misguided, because it prevents adding new parameters in 
> the future without breaking old implementations.
>
> Would you have us throw if 'audio' or 'video' were misspelled? If so, 
> how could we ever add a third media type like 'smellovision' ?

I would invoke a function that checks whether "smellovision" is 
supported by the browser, and throw an exception if "audio" or "video" 
are misspelled.

>>> What about: { audio: true, video: { optional: { maxW1dth: 320, 
>>> maxHeight: 240 }}}  ?
>>>
>>> or: { audio: true, video: { mandtory: { maxW1dth: 320, maxHeight: 
>>> 240 }}}  ? ...
>> I'm not advocating changing the language, just validating the 
>> function input.
>
> This is function input to gUM()! Would you have us fail on the two 
> cases above?

Yes, I would throw exceptions for the above two cases. Bad input data of 
any kind should trigger an exception.

Gili

Received on Friday, 6 December 2013 19:33:47 UTC