Stop using extended attributes for constructors

[Ms2ger]

Fixes #636.

---

Preview | Diff

[annevk]

Thanks for pushing this! I think we should wait with merging this until we have support on wpt/bikeshed, implementers are on board, and we have some number of specification PRs for this (I can help a bit next week). That seems preferable to slowly changing these things as then it might end up taking a long time for a full transition with lots of (costly) hiccups along the way.

[marcoscaceres]

@annevk is right. I can also help update legacy ReSpec specs using the old constructor.

@saschanaz and I can take care of things on WebIDL2.js, which WPT relies on.

[domenic]

Overall looks good; a few minor things to resolve.

In regard to ecosystem impact, what I'd really like to do is have a checklist of all specs to update. How long it takes us to update is less crucial to me, but having a corpus of all [Constructor]-using IDL and a list of specs we need to send PRs to would be a good idea.

@foolip or his team may know the latest on the "canonical IDL corpus" story?

[marcoscaceres]

@foolip @domenic, quick list from grepping wpt's interfaces directory:
https://gist.github.com/marcoscaceres/98241f92092132cba703e9be89500061

Gives us some idea... it looks like we would need to update ~75 specs.

[marcoscaceres]

Here is the list of matching files/specs: https://gist.github.com/marcoscaceres/c4d507839522d6bc96df23d460526c6a

[foolip]

https://github.com/tidoust/reffy-reports/tree/master/whatwg/idl is the source of the IDL files in WPT and what I've been treating as "all the web's IDL" for some time now.

I just finished fixing specs missed in the [NoInterfaceObject] interface+implements to interface mixin+includes transition, so making sure all changes have propagated to reffy-reports before using [Constructor] becomes invalid and is dropped from webidl2.js would be much appreciated.

[saschanaz]

What is this currently waiting for? Should issues be filed for browser implementations?

[bzbarsky]

Well, for starters it's not clear whether implementors are in fact on board...

[domenic]

Could you speak to that for Gecko? Chromium is on board.

[bzbarsky]

I am still sorting out the Gecko position here.

In terms of the actual change, after this you won't be able to use "constructor" as an argument name, dictionary member name, attribute name, or method name, unless you write it as _constructor. For attribute and method names this seems OK. For argument names, I'd suspect we want to add it to the ArgumentNameKeyword production, right? For dictionary members, do we want to allow it? It'd require a new production for dictionary member names, but that seems fine to me... and it would be potentially useful if people want to extract things like ES class info from objects via dictionaries.

I did just check and there are no existing IDLs in Gecko that use "constructor" in any of those situations, by the way.

[bzbarsky]

@domenic @Ms2ger it looks like the proposal disallows constructors on partial interfaces in prose, but it seems like we could do it on the syntax level now that there is an explicit syntactic construct. Could we do that? That check would be a lot more likely to actually get implemented in tools that way, I suspect, since just updating the grammar would do it.

[saschanaz]

A quick search on reffy-reports says the only place that uses the name constructor is CustomElementRegistry.

[bzbarsky]

OK, apart from the grammar issues mentioned above, I think Gecko is on board.

[bzbarsky]

Though I guess constructor is explicitly a reserved identifier (such that you can't use _constructor either, even without these changes).

In that case, the only grammar concern I have for now is the partial interface situation.

[Ms2ger]

Made the change for partial interfaces. I think that resolves everything besides the comment about "constructor method". I'll change that to "operation" tomorrow, but the PR should be ready for re-review now.

Who works on this for WebKit now? @rniwa?

[bzbarsky]

Looks reasonable to me. Would still like feedback from WebKit.

[Ms2ger]

Looks reasonable to me. Would still like feedback from WebKit.

@cdumez @youennf

[Ms2ger]

I propose we merge if Apple doesn't comment by next Monday, the 19th.

[youennf]

I see some potential future benefits but this seems quite a big syntactic change.
Is there any concrete plan for specs to use this new ability?

In terms of WebKit implementation, our constructor-specific keywords (canthrow, callwith, custom) have counterparts for operations, this seems fine and I quite like it in fact.

I wonder what the plan is for NamedConstructor.
WebKit implementation would need to keep these constructor-specific keywords around for NamedConstructor if it is not migrated as well.

[Ms2ger]

I'm expecting to file spec bugs based on a combination of scraping browser source code and adding errors in idlharness.js.

I think changing NamedConstructor as well would make sense, but don't have a timeline for that yet.

[domenic]

I'm not so sure about NamedConstructor, since that adds a factory function to the global, and doesn't add a member of the class (or effect the class in any way). Keeping it as-is seems better to me... Or if anything, making it a separate top-level declaration.