Re: Allow partial enums in return values?

* Jan-Ivar Bruaroey wrote:
>On 11/6/14 4:28 PM, bugzilla@jessica.w3.org wrote:
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27048
>
>Hi all,
>
>There's a case in WebRTC where we've instinctively defined the webidl 
>enum RTCStatsType for types of dictionaries returned from getStats(). [1]
>
>Since these are not living documents, other specs may want to extend 
>what stats a browser can return in the future - without having to update 
>webrtc-stats - so the group finds itself considering reverting 
>RTCStatsType to DOMString to allow for this [2].
>
>While an argument can probably be made that this is fair, going with 
>DOMString looses all the documentation and referencing benefits that 
>seemed inherently good - and still seem good - about having an 
>RTCStatsType in the first place. Furthermore, the reason for the 
>limitation only seems to make sense in the spec space, not the 
>implementation space (farewell binding code) or usage space.
>
>A plain string looses the idea that there are special strings that have 
>defined meanings.
>
>We also lose a place for other specs to link to when they extend the 
>definition, e.g. another spec might make up a string without reference.
>
>Is there room for a construct in-between string and enum here? A partial 
>enum? Other solutions?

It seems clear to me that you can keep using an `enum` and if need be
use prose to say "This specifications adds these values to that enum".
If you feel `enum` is the best fit for your use case, I do not think
reverting to DOMString is a good idea. It seems you are only looking
for WebIDL syntax to express adding values to an enum. That does not
look like a problem to me.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

Received on Saturday, 7 February 2015 11:50:54 UTC