- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 12 Dec 2013 13:00:32 -0500
- To: public-media-capture@w3.org
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'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.
Gili
Received on Thursday, 12 December 2013 18:01:32 UTC