Constructors and BCD

There are constructors defined by various specifications which have names different than that of the interface they allocate and return. For example, the HTMLImageElement interface has a constructor named Image(), so that you do new Image() to allocate a new <img> element.

Similarly, to allocate an <audio> element, you use new Audio().

These don’t really fit in our current model for BCD where we add the constructor as a method with the same name as the interface, since (of course) the name isn’t the same.

I think this is a problem we need to solve properly. I can think of two approaches:

Add a Constructors.json file

The first option is to add a Constructors.json file to BCD that lists these constructors using the same format we currently use for methods, except they’re all considered to be globals rather than members of an interface. The notes field can be used to define any details about whether they’re available from Window or Worker contexts, etc.

Add a new record to the InterfaceName.json files

The second option that comes to mind is that we could add to the top-level __compat block for an interface a new optional constructors field. This would result in BCD that looks something like the following.

{
  "api": {
    "HTMLAudioElement": {
      "__compat": {
        "mdn_url": "https://developer.mozilla.org/docs/Web/API/HTMLAudioElement",
        "constructors": [
        	"Audio": {
        	  "__compat": {
        	  	"mdn_url": "https://developer.mozilla.org/docs/Web/API/Constructor/Audio",
        	  	"description": "<code>new Audio()</code>",
        	  	...
        	  }
        	},
        	"HTMLAudioElement": {
        	  "__compat": {
        	  	"mdn_url": "https://developer.mozilla.org/docs/Web/API/HTMLAudioElement/HTMLAudioElement",
        	  	"description": "<code>new HTMLAudioElement()</code>",
        	  	...
        	  }
        	}
        ],
        "support": {
        	...
        }
      }
    }
  }
}

This allows for multiple constructors, possibly with different signatures, with compatibility tracked individually for each of those.