search

WICG / service-worker-static-routing-api

A repository for the ServiceWorker static routing API.
Other
24 stars 6 forks source link

Renaming attributes on Conditional Syntax #8

Closed azaika closed 11 months ago

azaika commented 11 months ago

The proposed Conditional Syntax ("or", "and", "not") [Design Doc] are all C++ keywords, and thus may prevent browsers from implementing this proposal. In fact, WebIDL binding tools for C++ in Chromium emit errors when I try to use the name "or".

Therefore, I suggest changing these names not to conflict with the C++ keywords. I think "any" and "all" are good alternatives.

chikamune-cr commented 11 months ago

The other possible alternatives of "and" and "or" could be "every" and "some" to be consistent with Array's every() and some(). The alternative of "not" could be "invert".

bathos commented 11 months ago

In fact, WebIDL binding tools for C++ in Chromium emit errors when I try to use the name "or".

It’s a unique terminal symbol in Web IDL, a keyword in union type syntax. The identifier with the string value “or” is written _or in Web IDL, with a leading underscore. It’s not related to C++.

Given there are existing Web IDL constructs with names that are C++ keywords such as default, continue, and operator (more: break, delete, inline, mutable, public, and register all show up), it would seem surprising to me if others led to conflicts. These identifiers are data from an impl POV: they get reified as string values in the ECMAScript binding, but the rest is imaginary.

Though it sounds like you encountered a facet of Web IDL syntax that you hadn’t previously and the C++ aspect of the comment was a red herring, it’s probably worth noting that naming decisions on the web platform aren’t / shouldn’t be determined by ephemeral concerns related to convenience to any particular implementation’s internals. I have no opinion on the names currently proposed or the alternatives given here, but that in itself would not be a legitimate motivation for a name choice. These would be.

azaika commented 11 months ago

@bathos Thank you for your kind comments. You are right: my concern was ephemeral.

I wrongly thought the conflict was unavoidable just because using only the leading underscore (_or) didn't work for me. However, I found that WebIDL's ImplmentedAs property, which was used to implement the continue feature you mentioned, solves the problem.