The Constrainable interface is polymorphic for no reason

Supplemental interfaces in WebIDL (or any other programming language) 
exist to solve a polymorphism problem where a client can use a single 
interface to interact with multiple objects. There is no such need with 
Constrainable, so it does not need to be a separate interface.

Which leads me to wonder: What exactly is the reuse case? Reusable by 
whom? Implementers? What exactly will they be reusing?

I can't imagine an implementation where MediaRecorder and getUserMedia 
rely on a common implementation of Constrainable, because, as an 
implementer, the parsing of inputs is not something I would farm out, as 
that would require translating it into something, and the inputs are 
already context-related intents in my implementation's domain (validated 
to boot if this had been unencumbered WebIDL).

So adding an abstraction here doesn't make a lot of sense to me as an 
implementer. The domains are discrete enough that any gain in shared 
parsing logic is more than offset by the building of a common backend to 
handle the different contexts correctly. There are better ways to share 
code and logic that don't affect an API.

I also fail to see where clients need this interface. Which leaves me 
with...

This whole thing appears driven by our needs to document the API, which 
is the tail wagging the dog.

I see damage to the API here to satisfy documentation concerns: The 
removal of context, abstraction of prose that used to be crisper, 
type-weakening (ConstraintValues abusing webidl unions), and 
domain-mixing (the settings set is a typeless bin across all future 
domains of use).

Similarly, IANA being a registry should not influence our API, but it 
has. It has driven us away from defining our API's inputs in WebIDL, to 
strings and some type-system rivaling WebIDL, again oddly for 
documentation reasons. I say oddly because I fail to see how this 
co-mingled indirection makes reading anything but unpleasant.

Documentation should document an API, not alter it. We should decide on 
the best API separately from how we go about documenting it.

.: Jan-Ivar :.

Received on Wednesday, 19 February 2014 22:07:16 UTC