Allow object for attribute names?

[saschanaz]

@gkellogg authoring JSON-LD 1.1 wants to use object as a valid attribute name. Obviously _object should work, but then object looks general enough for people to want using it without preceding underscore.

[annevk]

In general I'm in favor of not requiring folks to use underscores when it is possible to avoid doing so.

Is it possible to simplify some of this by for instance requiring that an interface/dictionary/enum/callback starts with a capital?

[bzbarsky]

I think just adding object to AttributeNameKeyword is workable. At least it does not seem to lead to any parsing ambiguities that I can find.

Doing something more generic, I'm not sure, not least in terms of how to express it to parsers.

[bathos]

@annevk I think the issue is in how the lexical grammar is defined rather than being about disambiguating top level syntactic constructs or idents within types.

If a literal teletype terminal appears anywhere in the grammar, it becomes a unique terminal which is subtracted from any pattern-based terminals that the same string would otherwise have matched. So if "object" appears as a literal terminal anywhere in the grammar, it isn’t an identifier, and to make it available as one, it has to be explicitly whitelisted as an alternative where that’s desired.

It’s an interesting lexical approach to the concept of reserved words — it simplifies some stuff, makes other things weird..

[annevk]

Thanks for explaining that @bathos! That helps a lot.

So https://heycam.github.io/webidl/#index-prod-Other has object as literal but also has AttributeNameKeyword. Wouldn't that create an ambiguity?

[bzbarsky]

We'd take the explicit "object" out of "Other" if we add it to "AttributeNameKeyword"