@@new

[Boris Zbarsky]

On 6/18/14, 1:46 PM, Domenic Denicola wrote:
> Yes, although in this case no initialization checks are necessary, just brand checks.

Well.  That depends on the desired behavior.

For example, say you have a DOMPoint as in your example above that is 
supposed to return Numbers for x and y.

In your pseudocode, what happens if .x or .y is accessed after @@create 
but before the constructor runs?  That depends on what slot 
initialization, if any, allocateNativeObjectWithSlots performs.  If a 
spec author wanted to not depend on implementation details like that, 
they would need to define that @@create puts something in the slots 
separate from whatever work the constructor does.

Note that at this point we're already forcing spec authors to think 
about the exact @@create behavior to make things subclassable and that 
in particular, every single existing spec that has a constructor will 
need to be revisited and modified as needed.

Doing an initialization check instead of a brand check would avoid 
needing to define @@create behavior in that sort of detail, I think, but 
adds extra checks that need to be performed, in addition to the brand 
check, and extra state (initialized or not) to be stored.

> Given how few DOM objects have reasonable constructors to begin with

I'm not sure how you're defining "reasonable", but a quick look at 
Gecko's IDL shows 136 IDL files that have at least constructor in them 
that takes some arguments and does not simply take a single optional 
argument (a dictionary, say).  For comparison, we have 586 IDL files 
total...

Some of these are not standards yet, and a few I think have a 
no-argument constructor in addition to the one with arguments, and a 
bunch are event constructors that would all presumably be defined in a 
similar way in the spec, but I think you're significantly 
underestimating the number of things that have constructors that 
actually do something with their arguments.

-Boris