- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Sun, 31 Jul 2011 17:04:47 -0700
- 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