Re: Dictionary-shaped Hammers

On 12/10/13 10:00 AM, Harald Alvestrand wrote:
> On 12/09/2013 06:03 PM, Martin Thomson wrote:
>>
>> The idea that a dictionary is appropriate here is, at best, a stretch.
>>   Don't look at every problem and assume that your hammer will work.  A
>> dictionary is not appropriate for this use case, and pretending that
>> it is does no favours to anyone.
>
> I find dictionaries an interesting concept, among other things because 
> they don't really exist in Javascript.

Show me one Javascript API that fails on unknown object properties.

> A dictionary is defined to have an automatic conversion from a 
> Javascript object to a dictionary - but that conversion is allowed to 
> lose information,

Dictionaries are extremely useful and make a lot of sense, because they 
have a much better security profile than object. The whole point is to 
narrow the API to known quantities, to give *implementers* the invariant 
they need to be effective and safe, because keeping javascript objects 
around is neither, since just one of them may contain an entire world. 
Unknowns are ignored until they're defined and we know their type. Seems 
natural and inherent when you think about it.

Webidl enums are equally interesting. Here the tree falls the other way, 
because bindings must throw on unknowns in order to ensure the 
implementer the invariant. Pick the right construct for the right task. 
(Btw, this means there's already no way to add new facingMode enums in 
the future without old browsers throwing, even in the optional block! - 
We sorely need a review here.)

> and we want some of the information that transformation is going to lose.

You said "we". Again, I disagree we want that information, because it 
only accomplishes total failure, all the time, for all cameras, 
correctly or not. I've proposed a simpler direct API, 
getKnownGumConstraints() for getting it, which seems popular, so the 
only remaining reason to keep the lost information would be to inflict 
failure on people who haven't thought about how they want to handle 
unknown keys. I think it's safer to violate the developer's invariant in 
this case than falsely block ALL users every time the browser falls 
behind on implementing a new mandatory constraint.

We need an adoption path for mandatory.
We need developers to consider all the available information before 
blanket failing.

My proposal accomplishes this.

> 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.

.: Jan-Ivar :.

Received on Thursday, 12 December 2013 15:57:53 UTC