Re: Non-constructible constructors and Arrays

(I have noted "require no-argument constructors on all interfaces" as 
Last Call comment LC-14.)

On 29/07/11 10:42 AM, David Flanagan wrote:
> But there must be *some* interfaces for which no constructors (with or
> without arguments) are desired... Perhaps the set of interfaces that do
> not want constructors is identical to the set that is currently declared
> [NoInterfaceObject] or [Callback]

I agree that there can be (and currently are) interfaces for which it 
does not make sense to be able to construct with zero arguments, at 
least not without also adding mutators on to the object so that 
"uninitialised" objects can be initialised after construction.

> I am not a spec writer, but it seems to me that since spec writers will
> have to write paragraphs of prose describing what each constructor does,
> it would actually be nicer to have those constructors explicitly
> declared in the IDL. Then, for example, the constructor declaration can
> be hyperlinked to the prose that defines what it does. With constructors
> created by default, spec authors will just have to remember to define
> the behavior of this important function that has no IDL representation.

I agree.  I think this kind of change -- requiring all Web API 
specification writers to define a the behaviour of a no-argument 
constructor -- will be hard to convince everyone to do.

Why not just file bugs on the specifications where such constructors do 
make sense to use [Constructor] or [NamedConstructor]?

> Adding constructors to all the DOM interfaces will be a non-trivial
> amount of work for the spec authors. It doesn't seem to me that
> modifying WebIDL to define constructors even without a [Constructor]
> declaration reduces that amount of work required in any substantial way.


> One WebIDL issue that might be worth changing is to require named
> constructors to have the same prototype object as the current interface
> object. For example, WebIDL should probably require that:
> Image.prototype === HTMLImageElement.prototype
> Currently this comparison is false in both FF and Chrome.

Noted as Last Call LC-15.  Alex's suggestion later in the thread to make 
NamedConstructorName === InterfaceName (like Image === HTMLImageElement) 
would be OK only if we know/require that the constructors on both names 
are the same.

Received on Sunday, 31 July 2011 23:29:30 UTC