[Bug 27048] Allow partial enums

# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27048

Anne annevk@annevk.nl changed:

       What    |Removed                     |Added

             CC|                            |annevk@annevk.nl

--- Comment #1 from Anne annevk@annevk.nl ---

That is not an ideal way of writing specifications. With all the bits fragmented. We have some of that already today and it is rather painful for implementers. What is wrong with reviving the base specification?

Contact us to advertise here
# bugzilla at jessica.w3.org (3 years ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27048

Mounir Lamouri mounir@lamouri.fr changed:

       What    |Removed                     |Added

             CC|                            |w3c@marcosc.com

--- Comment #2 from Mounir Lamouri mounir@lamouri.fr ---

We are actually considering using an enum in the specification now.

# bugzilla at jessica.w3.org (a year ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27048

Tobie Langel tobie.langel@gmail.com changed:

       What    |Removed                     |Added

             CC|                            |tobie.langel@gmail.com

--- Comment #3 from Tobie Langel tobie.langel@gmail.com ---

So this issue was brought up again today as I'm moving forward with the Generic Sensor API.

Here's the concrete use case:

The editor writes a spec for the Heartbeat Sensor. Said spec obviously requires permissioning. Currently this requires amending the Permissions API to add a corresponding string (e.g. "heartbeat-sensor") to the PermissionName Enum1.

Now, what happens when an implementor decides to implement the Permissions API, but not the Heartbeat sensor? Will he filter the corresponding string out of the enum?

If an implementor decides to implement the Heartbeat Sensor API, then removes it because it turns out the privacy concerns are to big, aren't the risks of forgetting to modify the enum higher if it lies in the Permissions API? In that case, developers could potentially have the Permission's API tell them the user has granted access to a sensor that's no longer implemented. Seems strange.

None of these are an issue if the "heartbeat-sensor" string is added to the PermissionName Enum1 from the Heartbeat Sensor spec itself. I'm also not sure there are any downsides to having a split enum in this concrete example. Quite the contrary, actually, as it seems much more logical to split cross-cutting concerns like these across specs.

(Note I'm not suggesting that partial enums are the right choices in all use cases, but it's not because a hammer isn't the appropriate tool to fix a pair of glasses that a carpenter shouldn't be able to use one.)

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27048

--- Comment #4 from Harald Alvestrand harald@alvestrand.no ---

This bug has been open for 2 years. Can we either get it added to the spec or definitely rejected as a bad idea, so that people won't have hope that it will be added?

(I have need for this type of functionality in making valid IDL for the relationshiop between w3c.github.io/webrtc-stats/webrtc-stats.html and w3c.github.io/webrtc-pc/webrtc.html. If we can't have extensible enums, I'm going to suggest that we use a DOMString instead.)

# bugzilla at jessica.w3.org (8 months ago)

www.w3.org/Bugs/Public/show_bug.cgi?id=27048

Domenic Denicola d@domenic.me changed:

       What    |Removed                     |Added

             CC|                            |d@domenic.me

--- Comment #5 from Domenic Denicola d@domenic.me ---

As with many specs, Web IDL has overtaxed editors and a large backlog of bugs, several of which are more urgent than this one. If this is truly important to you, a pull request to add the feature to Web IDL would be excellent, as for example Jeffrey has recently done to close out the long-standing "open ended dictionary" feature.

Want more features?

Request early access to our private beta of readable email premium.