From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> Hmm. So given the current direction whereby ES6 constructors may not even be
> [[Call]]-able at all, I'm not sure we have any great options here. :(
> Basically, ES6 is moving toward coupling allocation and initialization but
> the upgrade scenario can't really be expressed by coupled alloc+init if it
> preserves object identity, right?
Yes, that is my feeling exactly. The old @@create design was perfect for our
purposes, since its two-stage allocation-then-initialization could be staged
appropriately by doing allocation initially, then initialization upon
upgrading. But the new coupled design defeats that idea.
>> I was hopeful that ES6 would give us a way out of this, but after thinking
>> things through, I don't see any improvement at all. In particular it seems
>> you're always going to have to have `var C2 =
>> document.registerElement("my-el", C1)` giving `C2 !== C1`.
>
> This part is not immediately obvious to me. Why does that have to be true?
Well, I was skipping several steps and making a few assumptions. Roughly, my
thought process was that you want *some* constructor that corresponds to
parser/document.createElement behavior. And, since as discussed it definitely
can't be your own constructor, the browser will need to generate one for you.
Thus, it'll generate C2, which is different from the C1 you passed in.
Even if you removed the assumption that having a (user-exposed) constructor
that corresponds to parser behavior is useful, it doesn't fix the issue that
the C1 constructor is useless.
