Re: Non-constructible constructors and Arrays

On 9/9/11 4:24 AM, Alex Russell wrote:
>>   Specification writers need to write the actual behaviour for these
>> constructors whether they are implicitly declared or not.
>
> The default behavior would simply be to generate objects of those
> types without side effects.

What if there are not normally objects of those types?  Or more than one 
kind of object of those types?

For example, what should |new Element()| do if the specification doesn't 
define it?   There's no sane behavior, because you have no idea what tag 
name to give it.

You can find some examples where the behavior is "clear"... But even in 
the |new HTMLDivElement| case, what would define what the ownerDocument 
of the new element is?  WebIDL itself certainly can't make such a 
definition.  The fact that an ownerDocument even exists is specific to 
the HTMLDivElement interface, and whatever spec defines that interface 
would need to explicitly address that.

> In any case, it repairs the mental model of the mappings between JS
> and DOM where in JS, functions can *always* be invoked via "new",

That's because nothing requires a function thus invoked to return 
anything useful.

We could, of course, define that a |new Interfacename| returns 
Object.create(Interfacename.prototype), unless the spec defining 
Interfacename says otherwise; that's basically the JS function behavior. 
  Is that what you're actually asking for?  What would you do with such 
an object?

> whereas WebIDL makes interfaces these alien things which, by default,
> don't do "the right thing" from the JS perspective.

Nothing prevents a JS function from throwing if invoked via |new|.  If 
you prefer to think of it that way, that's all that's happening here.

-Boris

Received on Friday, 9 September 2011 18:16:15 UTC