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

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

From: Mark S. Miller <erights@google.com>
Date: Fri, 11 Jun 2010 20:00:26 -0400
Message-ID: <AANLkTin_jGLLozPHR6zWNofi0gdROP2UU2DTaFFYsvOF@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
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
On Fri, Jun 11, 2010 at 6:15 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> On Jun 11, 2010, at 3:05 PM, James Graham wrote:
> > Quoting Travis Leithead <travil@microsoft.com>:
> >
> >> The way I interpret that, [[Call]] should equal [[Construct]] in all
>  cases for host objects. Why? Because real-world code using  XMLHttpRequest
> today mixes and matches the invocation pattern:
> >> 'new XMLHttpRequest;'
> >> 'new XMLHttpRequest();'
> >> 'XMLHttpRequest();'
> >>
> >> and for web-compat, we want all of these to succeed.
> >
> > Arguably the XMLHttpRequest spec special cases this so all three forms
> > work at [1] (I am not sure what exactly is meant by "constructor is
> > invoked" here since it could mean "[[Construct]] method is called" or
> > "[[Call]] method is called"; this should probably be clarified in the
> > spec). Therefore that is not a good example from which to derive a
> > general rule.
> >
> > On general principles I would prefer [[Call]] === [[Construct]] for
> > new host object constructors; it seems closest to the behaviour of
> > ECMAScript builtins and convenient for authors, but for legacy
> > constructors we probably need to mimic deployed UA behaviour.
> 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.

When a normal function F ignores its "this" and returns an object, prefixing
a call to F with "new" results in no change in behavior. When there are no
legacy compat issues saying otherwise, I think this is how new
functions-which-make-things should be defined. The proposed Proxy.create,
Proxy.createFunction, and EphemeronTable are all speced to work that way, as
are the classes-as-sugar and traits strawmen. I like the idea that WebIDL
[Constructor] should as well.

>  - Maciej

Received on Saturday, 12 June 2010 00:00:55 UTC

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