Re: Dictionary-shaped Hammers

On 12/12/13 1:00 PM, cowwoc wrote:
> On 12/12/2013 12:15 PM, Jan-Ivar Bruaroey wrote:
>> On 12/12/13 10:57 AM, Jan-Ivar Bruaroey wrote:
>>>> I'd like to preserve two properties of our current spec:
>>>>
>>>>  - That we can get an error on unsupported constraint names
>>>>  - That we can get automatic conversion from objects specified in 
>>>> Javascript as { name : value }
>>>>
>>>> As long as I get those two properties, I don't care what the name 
>>>> of the construct is.
>>>
>>> Your construct is object.
>>
>> While I continue to find our default behavior misguided, I'd be 
>> remiss not to mention a suggestion I heard that it might be doable to 
>> argue for a [ThrowOnUnknownKeys] extended attribute for dictionaries. 
>> This means we'd get an error thrown instead of an error callback in 
>> the case of unknown keys. Would that be acceptable?
>>
>> Separately, we could try arguing for a 
>> [ConvertUnknownEnumerationValuesTo="other"] extended attribute to 
>> solve webidl enums throwing in optional.
>
> If you are implying the code should throw an exception synchronously, 
> instead of returning it asynchronously through the error callback then 
> I'm against that proposal. 

I think I described the behavior explicitly, not implying it, but OK.

> I'm looking at this through a "Promises" lens which says that all 
> errors should be returned through the Promise (or in our case, the 
> callback). I don't see the benefit of asking developers to check for 
> errors in two different places.

FWIW it is not the case that there wont be exceptions. The spec is 
expressed largely in WebIDL, which implies lots of argument 
validity-checking and type-checking using exceptions. Try passing a 
number in place of a required object argument for instance, or (as I 
pointed out already) a facingMode constraint you never heard of, 
mandatory or optional.

I opened with saying I'm opposed to fail-always on unknown mandatory 
constraints, but if we want that behavior, then arguably, treating an 
unknown-to-the-UA object-property as a type-error doesn't seem totally 
unreasonable to me. After all, the app is trying to use a feature the 
browser doesn't understand. This would be a way to get the fail-always 
behavior others here desire and still use dictionaries. It is a compromise.

I like that this at least differentiates between "the browser cannot 
tell" and "the camera for-sure does not have the feature", which are not 
the same thing, and something we seem to conflate whenever we talk about 
this (ignoring the false-negative problem's existence).

As to promises, I believe they handle exceptions. From 
http://blog.parse.com/2013/01/29/whats-so-great-about-javascript-promises :
  "Generally, developers consider a failing promise to be the 
asynchronous equivalent to throwing an exception. In fact, if a callback 
passed to 'then' throws an error, the promise returned will fail with 
that error."

> Gili

.: Jan-Ivar :.

Received on Thursday, 12 December 2013 21:08:11 UTC