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

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
>
>
>
>


-- 
    Cheers,
    --MarkM