W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2010

Re: [WebIDL] interface objects with [Constructor] and [[Call]]

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 11 Jun 2010 16:42:04 -0700
Cc: James Graham <jgraham@opera.com>, Travis Leithead <travil@microsoft.com>, Simon Pieters <simonp@opera.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, annevk@opera.com
Message-id: <C71E78A4-25AA-400F-847C-553FB5B7F89A@apple.com>
To: Brendan Eich <brendan@mozilla.org>

On Jun 11, 2010, at 3:34 PM, Brendan Eich wrote:

> On Jun 11, 2010, at 11:31 PM, James Graham wrote:
>> On Fri, 11 Jun 2010, Maciej Stachowiak wrote:
>>> Another possibility when there are no legacy constraints is to not implement [[Call]], so that there is only one way to invoke the constructor. For vanilla JS functions, calling them with and without "new" has quite different behavior. And for many builtins, calling with and without "new" actually does subtly different things. Thus, I don't think we want to encourage developers to mix and match.
>> Fair enough, unless the legacy points us strongly in the other direction.
> For XMLHttpRequest, Travis claimed legacy is in the other direction.

We definitely shouldn't change XMLHttpRequest itself. This would be an open question for new Webbish APIs that expose constructors, such as WebSocket or Worker.

> JS is not a B&D language, so I'm more in favor of [[Call]] == [[Construct]]. Unless there is future-proofing benefit in reserving [[Call]]. And the horses are not already out of the barn.

I don't feel very strongly about this either way.

Received on Friday, 11 June 2010 23:42:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC