@@new

[Erik Arvidsson]

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 <erik.arvidsson at gmail.com>
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 <
> jason.orendorff at gmail.com> wrote:
>
>> On Tue, Jun 17, 2014 at 6:55 PM, Erik Arvidsson
>> <erik.arvidsson at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140618/0f750e54/attachment-0001.html>