Re: Non-constructible constructors and Arrays

On Fri, Sep 9, 2011 at 1:14 AM, Cameron McCormack <> wrote:
> On 9/09/11 4:45 PM, Alex Russell wrote:
>> Wait, why shouldn't I be able to new-up a CharachterData item?
> It's more of an abstract interface/class.  There's no DOM Node type that
> corresponds to CharacterData.
>> And in any case, if the *default* is to want this, why not simply flip
>> things the other way, add a new noconstructor attribute or similar?
> Flipping the default isn't going to cause useful constructors to exist.

It will, however, set the precedent that constructors *should* exist.

>  Specification writers need to write the actual behaviour for these
> constructors whether they are implicitly declared or not.

The default behavior would simply be to generate objects of those
types without side effects. E.g., without a smarter ctor that accepts
arguments, new HTMLDivElement() == document.createElement("div").

Not sure why that's a bad thing. Yes, HTML DOM can (and should!) do
something smarter, but this is clearly a step in the right direction.

In any case, it repairs the mental model of the mappings between JS
and DOM where in JS, functions can *always* be invoked via "new",
whereas WebIDL makes interfaces these alien things which, by default,
don't do "the right thing" from the JS perspective.

>  I think the right
> thing to do here is just to file bugs on specifications and get them to add
> constructors for existing interfaces.  This has already started happening
> recently with the Event interfaces.

Received on Friday, 9 September 2011 08:25:20 UTC