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

Re: Non-constructible constructors and Arrays

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Sun, 31 Jul 2011 17:04:47 -0700
Message-ID: <CABZUbM3HPd5QEbDv35-ORtg02Hjb5qLShc+Zs7r0nDZh4jgurQ@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: David Flanagan <dflanagan@mozilla.com>, Alex Russell <slightlyoff@google.com>, public-script-coord@w3.org, Brendan Eich <brendan@mozilla.com>
On 7/31/11, Cameron McCormack <cam@mcc.id.au> wrote:

[...]
> 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.
>
Even harder to enforce.

> 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.
>
> Right.
>
Yep, I agree -- making every Interface Object a constructor doesn't
make sense. And I think it was I who brought that up first (at least
in this thread).

But for constructors that are specified, what happens when an argument
is missing should be defined, even if to say throw a DOMException
TYPE_MISMATCH_ERR (or possibly TypeError if that is not too radical an
idea). That at least avoids the opportunity for interpreting whether
or not `undefined` should be "" or "undefined", an error, etc.

For API consistency, EcmaScript internal operations should be used for
type conversion, i.e. ToBoolean, ToString, etc. See also:
http://es5.github.com/#x9
-- 
Garrett
Received on Monday, 1 August 2011 00:05:20 UTC

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