W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: Non-constructible constructors and Arrays

From: Alex Russell <slightlyoff@google.com>
Date: Tue, 13 Sep 2011 15:37:48 -0700
Message-ID: <CANr5HFWJz+VFzODq_3xGOdOtLRCxBwBivc05+sPoAz2G6A+KQA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Sep 9, 2011 at 2:01 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 9/9/11 3:04 PM, Garrett Smith wrote:
>>
>> OK, so in the case of Element, that would be web dom core, right?
>> http://www.w3.org/TR/domcore/
>
> Yes.  But the point is that if the spec needs to worry about the constructor
> no matter what, WebIDL's claiming that there is a constructor by default is
> not very useful.  In my opinion.

That's vs. the current state, in which *most* spec authors simply fail
to add constructors of any type and aren't bothered with questions of
what they should look like, since the easiest thing to do is to simply
screw over JS devs and leave the problem unaddressed. Forcing the
issue *is progress*, not a reason not to do it.

>>> Is this really such a hard concept to grasp?  I'm getting the feeling
>>> that people are really confused about what WebIDL itself can define and
>>> what specs using WebIDL as their interface description language can
>>> define...
>>>
>> "This document defines an interface definition language, Web IDL, that
>> can be used to describe interfaces that are intended to be implemented
>> in web browsers."
>>
>> So essentially, you want to describe in a general sense how interface
>> objects work and leave the specifics of how they're implemented to the
>> specifications in which define them. Did I get that right?
>
> That's how it works, yes....  In particular, WebIDL itself cannot say
> anything about how any _particular_ interface behaves.
>
> -Boris
>
Received on Tuesday, 13 September 2011 22:38:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC