- From: Alex Russell <slightlyoff@google.com>
- Date: Fri, 9 Sep 2011 01:24:18 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On Fri, Sep 9, 2011 at 1:14 AM, Cameron McCormack <cam@mcc.id.au> 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