Another thing to consider is to ensure that @@create initializes all of its slots. For example Date[@@create]() could set its [[DateValue]] to NaN, Map[@@create]() could set its [[MapData]] to an empty list and so on.
This also fits how @@create works for DOM, where the creation of the instance would set up the internal DOM wrapper pointer, never exposing a non initialized DOM object to user code. On Wed, Jun 18, 2014 at 11:33 AM, Erik Arvidsson <[email protected]> wrote: > What about the other direction? > > class B { > constructor(x) { > this.x = x; > } > static [Symbol.create]() { > var o = super(); > weakMap.set(o, 12345678); // DOM wrapper foo > return o; > } > } > > function C(x) { > B.call(this, x); > } > C.__proto__ = B; > C.prototype = {__proto__: B.prototype}; > > > I think the most concerning part of this proposal is that > `constructor(...)` gets replaced by `static [Symbol.new](...)` with strange > semantics regarding `this`. If we instead had @@new call constructor by > default I think most of these concerns go away but then again we are back > to two initialization functions and the possibility to observe an object > that never went through its constructor. > > > > On Tue, Jun 17, 2014 at 8:03 PM, Jason Orendorff < > [email protected]> wrote: > >> On Tue, Jun 17, 2014 at 6:55 PM, Erik Arvidsson >> <[email protected]> wrote: >> > How does this work with legacy classes? >> > >> > function B() { >> > this.x = 1; >> > } >> > class C extends B {} >> >> That works! >> >> `new C` desugars to `C[@@new]()`. C doesn't have a @@new method of >> its own, so it inherits `Function.prototype[@@new]`. >> >> The algorithm for that method is given in the proposal. Step 1 selects >> the right prototype here (C.prototype), and step 4 calls B as desired. >> >> -j >> > > > > -- > erik > -- erik
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
