bzbarsky at MIT.EDU
Wed Jun 18 12:01:04 PDT 2014
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
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.
More information about the es-discuss