- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Mar 2015 19:26:02 +0000
- To: public-media-capture-logs@w3.org
I'm happy we're getting explicit WebIDL types, but I agree with
@dontcallmedom . For implementors, having four places to maintain and
update (Supported, Settings, Capabilities and Constraints) for each
new constraint added, is a cost. For readers, the syntactic symmetry
and relationship between four seemingly discrete types is buried in
prose, a missed opportunity for clarity through types IMHO. I can't
think of an API where I've seen member-sets transcend types like this,
so it may in fact be unprecedented as well. We may have cut the cake
wrong somewhere when similar member-sets are not even rooted in a
shared base type.
The spec is full of assumptions that constraints and settings are
related in a member-by-member enumeration: " If the constraint is
required ('min', 'max', or 'exact'), and the settings dictionary's
value for the constraint does not satisfy the constraint, use positive
infinity." - but oddly, I can't find a definition of "satisfied"
anywhere.
The discrete typing seems especially egregious for
getSupportedConstraints(), an API that literally tells you what
members the dictionary MediaTrackConstraintSet supports! Seeing a
member in the returned dictionary would *inherently* prove that
MediaTrackConstraintSet supports it, *provided it actually returned a
MediaTrackConstraintSet dictionary*. This seems so intuitive that I'm
having a hard time explaining why a different type makes no sense.
--
GitHub Notif of comment by jan-ivar
See
https://github.com/w3c/mediacapture-main/pull/143#issuecomment-82554486
Received on Tuesday, 17 March 2015 19:26:22 UTC