allenwb · August 29, 2015 14:05 · Sep 11, 2014 · Sep 11, 2014 · Sep 11, 2014 · Sep 5, 2014
diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -87,7 +87,7 @@ we now expect programmers to be explicit about their intent by saying:
 ```
 No magic, everything is explicit, and it is possible to statically dermine whether a constructor is intended to perform its own allocation and binding of its **this** value. 
 
-###Rational for change #3
+###Rationale for change #3
 Once you have #2, #3 naturally follows and as we've shown there are [lots of use cases](https://gist.github.com/allenwb/53927e46b31564168a1d#usage-pattern-for-a-proposed-new-es6-constructor-semantics) for constructors that don't just do the default ordinary allocation.
 
 Change #3 also reduces the difference (and refactoring expense) between common constructor patterns and constructors that do special allocation steps:

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -44,7 +44,7 @@ Subsequent to this meaning we extensively discussed, refined and polished the de
 2.  Requiring an explicit `this=` rather than making the first `super()` call implicitly assign to **this**.
 3.  Allowing anything to be assigned to **this** from within the **this** TDZ of a constructor.
 
-###Rational for change #1
+###Rationale for change #1
 Consider a constructor such as: 
 ```js
 class D extends B {
@@ -59,7 +59,7 @@ Which of the `super()` expressions will do [[Construct]] invocation and which wi
 
 We already have enough confusions between "called as a function" and "called as a constructor".  As part of this proposal, for the first time, ECMAScript will allow a constructor to dynamically determine which way it was called.  In general `x()` means invoke via [[Call]] and `new x()` means invoke via [[Construct]].  It would terrible to further confuse things by introducing special situations where `super()` means [[Construct]] and not [[Call]].  If the ES programmer is thinking I need to let my base constructor create an object, then `new super()`, is exactly the appropiate idiom and the right way to think about it.  Other languages that use `super()` for this purpose don't have the language level distinction between [[Call]] and [[Construct]].
 
-###Rational for change #2
+###Rationale for change #2
 
 As discussed at the July meeting, `super()`, would magically bind **this** if it occurs in the **this** TDZ.  We should be adding additional "magic" behavors to ECMAScript: a hidden implicit binding construct.  The intent of explicitly setting **this** is much clearer then `super()` which might might or might not be intended to set **this** (or be a [[Call]] or [[Construct]] depending upon what has already happened in the method.
 

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -49,7 +49,7 @@ Consider a constructor such as:
 ```js
 class D extends B {
    constructor () {
-      If (!this^) super();
+      If (!new^) super();
       if (Math.random() >0.5) super();
       f(super());
    }
@@ -103,7 +103,7 @@ Typically a constructor might look like this:
 But without #3, a constructor that does special allocation might look like:
 ```js
    constructor(a,b) {
-      let newObj = this^.specialAllocationMethod();
+      let newObj = new^.specialAllocationMethod();
       newObj.a = a;
       newObj.b = b;
       return newObj.
@@ -112,7 +112,7 @@ But without #3, a constructor that does special allocation might look like:
 With #3 such a constructor can be expressed as:
 ```js
    constructor(a,b) {
-      this = this^.specialAllocationMethod();
+      this = new^.specialAllocationMethod();
       this.a = a;
       this.b = b;
    }

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -63,12 +63,20 @@ We already have enough confusions between "called as a function" and "called as
 
 As discussed at the July meeting, `super()`, would magically bind **this** if it occurs in the **this** TDZ.  We should be adding additional "magic" behavors to ECMAScript: a hidden implicit binding construct.  The intent of explicitly setting **this** is much clearer then `super()` which might might or might not be intended to set **this** (or be a [[Call]] or [[Construct]] depending upon what has already happened in the method.
 
+Semantically, alloowing `super()` to mean either [[Construct]] or [[Call]] makes it impossible to statically make the determination of which is meant.  Consider the following example:
+```js
+  constructor() {
+    let randomize = o => Math.random()>=0.5 ? !!o: !o;
+    if (randomizer(new^)) return super(); //is this a [[Call]] or [[Construct]]?
+  }
+```
+
 Changes #1 and #2 fit naturally together.  Where in previous designs we expected programmer to know the magic and say" 
 ```js
-   constructor() {
-      super();  //looks like a [[Call]] acts as a [[Construct]] and sets this
-      this.newProp = ...
-   }
+  constructor() {
+    super();  //looks like a [[Call]] acts as a [[Construct]] and sets this
+    this.newProp = ...
+  }
 ```
 we now expect programmers to be explicit about their intent by saying:
 ```js
@@ -77,7 +85,7 @@ we now expect programmers to be explicit about their intent by saying:
       this.newProp = ...
    }
 ```
-No magic, everything is explicit. 
+No magic, everything is explicit, and it is possible to statically dermine whether a constructor is intended to perform its own allocation and binding of its **this** value. 
 
 ###Rational for change #3
 Once you have #2, #3 naturally follows and as we've shown there are [lots of use cases](https://gist.github.com/allenwb/53927e46b31564168a1d#usage-pattern-for-a-proposed-new-es6-constructor-semantics) for constructors that don't just do the default ordinary allocation.

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -57,11 +57,11 @@ class D extends B {
 ```
 Which of the `super()` expressions will do [[Construct]] invocation and which will do [[Call]] invocation? How does it change if the code is refactored? What happens if a **new** is put in front of any of the above `super()` expressions? Does it change the semantics of any, some, or all of them?
 
-We already have enough confusions between "called as a function" and "called as a constructor".  As part of this proposal, for the first time, ECMAScript will allow a constructor to dynamically determine which way it was called.  In general `x()` means invoke via [[Call]] and `new x()` means invoke via [[Construct]].  It would terrible to further confuse things by introducing special situations where `super()` means [[Construct]] and not [[Call]].  If the ES programmer is thinking I need to invoke my base constructor, then `new super()`, is exactly the appropiate idiom and the right way to think about it.  Other languages that use `super()` for this purpose don't have the language level distinction between [[Call]] and [[Construct]].
+We already have enough confusions between "called as a function" and "called as a constructor".  As part of this proposal, for the first time, ECMAScript will allow a constructor to dynamically determine which way it was called.  In general `x()` means invoke via [[Call]] and `new x()` means invoke via [[Construct]].  It would terrible to further confuse things by introducing special situations where `super()` means [[Construct]] and not [[Call]].  If the ES programmer is thinking I need to let my base constructor create an object, then `new super()`, is exactly the appropiate idiom and the right way to think about it.  Other languages that use `super()` for this purpose don't have the language level distinction between [[Call]] and [[Construct]].
 
 ###Rational for change #2
 
-As discussed at the July meeting, `super()`, would magically bind **this** if it occurs in the **this** TDZ.  We should be adding additional "magic" behavors to ECMAScript or hidden implicit binding constructs.  The intent of explicitly setting **this** is much clearer then `super()` which might might or might not be intended to set **this** (or be a [[Call]] or [[Construct]] depending upon what has already happened in the method.
+As discussed at the July meeting, `super()`, would magically bind **this** if it occurs in the **this** TDZ.  We should be adding additional "magic" behavors to ECMAScript: a hidden implicit binding construct.  The intent of explicitly setting **this** is much clearer then `super()` which might might or might not be intended to set **this** (or be a [[Call]] or [[Construct]] depending upon what has already happened in the method.
 
 Changes #1 and #2 fit naturally together.  Where in previous designs we expected programmer to know the magic and say" 
 ```js

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -40,7 +40,7 @@ The main innovation present at the meeting was the introduction of a new syntact
 
 Subsequent to this meaning we extensively discussed, refined and polished the design. In addition to changing `new*` to `new^` there we made three other major changes:
 
-1.  Using 'new super()' rather than `super()` as the invocation of the super constructor via [[Construct]]
+1.  Using `new super()` rather than `super()` as the invocation of the superclass constructor via [[Construct]]
 2.  Requiring an explicit `this=` rather than making the first `super()` call implicitly assign to **this**.
 3.  Allowing anything to be assigned to **this** from within the **this** TDZ of a constructor.
 
@@ -55,25 +55,25 @@ class D extends B {
    }
 }
 ```
-Which of the `super()` expressions will do [[Construct]] invocation and which will do [[Call]] invocation? How does it change if the code is refactored? What happens if a *new* is put in front of any of the above `super()` expressions? Does it change the semanitics of any, some, or all of them?
+Which of the `super()` expressions will do [[Construct]] invocation and which will do [[Call]] invocation? How does it change if the code is refactored? What happens if a **new** is put in front of any of the above `super()` expressions? Does it change the semantics of any, some, or all of them?
 
-We already have enough confusions between "called as a function" and "called as a constructor".  A part of this proposal, for the first time, ECMAScript will allow a constructor to dynamically determine which way it was called.  In general `x()` means invoke via [[Call]] and `new x()` means invoke via [[Construct]].  It would terrible to further confuse things by introducing special situations where `super()` means [[Construct]] and not [[Call]].  If the ES programmer is thinking I need to invoke my base constructor, then `new super()`, is exactly the appropiate idiom and the right way to think about it.  Other languages that use `super()` for this purpose don't have the language level distinction between [[Call]] and [[Construct]].
+We already have enough confusions between "called as a function" and "called as a constructor".  As part of this proposal, for the first time, ECMAScript will allow a constructor to dynamically determine which way it was called.  In general `x()` means invoke via [[Call]] and `new x()` means invoke via [[Construct]].  It would terrible to further confuse things by introducing special situations where `super()` means [[Construct]] and not [[Call]].  If the ES programmer is thinking I need to invoke my base constructor, then `new super()`, is exactly the appropiate idiom and the right way to think about it.  Other languages that use `super()` for this purpose don't have the language level distinction between [[Call]] and [[Construct]].
 
 ###Rational for change #2
 
-As discussed at the July meeting, `super()`, would magically bind **this** if it occurs in the **this** TDZ.  I say less magic, and no hidden implicit binding.  The intent of explicitly setting **this** is much clearer then `super()` which might might or might not set **this** (or be a [[Call]] or [[Construct]] depending upon what has already happened in the method.
+As discussed at the July meeting, `super()`, would magically bind **this** if it occurs in the **this** TDZ.  We should be adding additional "magic" behavors to ECMAScript or hidden implicit binding constructs.  The intent of explicitly setting **this** is much clearer then `super()` which might might or might not be intended to set **this** (or be a [[Call]] or [[Construct]] depending upon what has already happened in the method.
 
 Changes #1 and #2 fit naturally together.  Where in previous designs we expected programmer to know the magic and say" 
 ```js
    constructor() {
-      super();  //looks like a [[Call]] acts as a [[Cponstruct]] and sets this
+      super();  //looks like a [[Call]] acts as a [[Construct]] and sets this
       this.newProp = ...
    }
 ```
-we now expect to be explicit about their intent by saying:
+we now expect programmers to be explicit about their intent by saying:
 ```js
    constructor() {
-      this:= new super();  //always a [[Construct]], explicitly binds ths
+      this = new super();  //always a [[Construct]], explicitly binds ths
       this.newProp = ...
    }
 ```
@@ -82,7 +82,7 @@ No magic, everything is explicit.
 ###Rational for change #3
 Once you have #2, #3 naturally follows and as we've shown there are [lots of use cases](https://gist.github.com/allenwb/53927e46b31564168a1d#usage-pattern-for-a-proposed-new-es6-constructor-semantics) for constructors that don't just do the default ordinary allocation.
 
-It also, reduces the difference (and refactoring expense) between constructors common constructor patterns and constructors that do special allocation steps:
+Change #3 also reduces the difference (and refactoring expense) between common constructor patterns and constructors that do special allocation steps:
 
 Typically a constructor might look like this:
 ```js
@@ -101,7 +101,7 @@ But without #3, a constructor that does special allocation might look like:
       return newObj.
    }
 ```
-With #3 this can be expressed as:
+With #3 such a constructor can be expressed as:
 ```js
    constructor(a,b) {
       this = this^.specialAllocationMethod();

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -36,13 +36,13 @@ e.g. using `new C(...args)`:
 >3.  During phase /* 3 */, the this-binding is initialised, and any call to a 
    super-method has the normal semantics of method (not constructor).
 
-The main innovation present at the meeting was the introduction of a new syntactic token `new*` that can be used to distigish a [[Construct]] initiated evaluation of a constructor from a [[Call]] initialed evaluation. 
+The main innovation present at the meeting was the introduction of a new syntactic token `new*` that can be used to distigish a [[Construct]] initiated evaluation of a constructor from a [[Call]] initiated evaluation. 
 
-Subsequent to this meaning we refined and polished the design.  In addition to changing `new*` to `new^` there we made three major changes:
+Subsequent to this meaning we extensively discussed, refined and polished the design. In addition to changing `new*` to `new^` there we made three other major changes:
 
-1  Using 'new super()' rather than 'super()' as the invocation of the super constructor via [[Construct]]
-2  Requiring an explicit "this=" rather than making the first super() call implicitly assign to this.
-3  Allowing anything to be assigned to "this" when it is in its TDZ of its constructor.
+1.  Using 'new super()' rather than `super()` as the invocation of the super constructor via [[Construct]]
+2.  Requiring an explicit `this=` rather than making the first `super()` call implicitly assign to **this**.
+3.  Allowing anything to be assigned to **this** from within the **this** TDZ of a constructor.
 
 ###Rational for change #1
 Consider a constructor such as: 

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -36,7 +36,7 @@ e.g. using `new C(...args)`:
 >3.  During phase /* 3 */, the this-binding is initialised, and any call to a 
    super-method has the normal semantics of method (not constructor).
 
-The main innovation present at the meeting was the introduction of a new syntactic token `new*` that can be used to distigish a [[Constructor]] initiated evaluation of a constructor from a [[Call]] initialed evaluation. 
+The main innovation present at the meeting was the introduction of a new syntactic token `new*` that can be used to distigish a [[Construct]] initiated evaluation of a constructor from a [[Call]] initialed evaluation. 
 
 Subsequent to this meaning we refined and polished the design.  In addition to changing `new*` to `new^` there we made three major changes:
 

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -82,5 +82,39 @@ No magic, everything is explicit.
 ###Rational for change #3
 Once you have #2, #3 naturally follows and as we've shown there are [lots of use cases](https://gist.github.com/allenwb/53927e46b31564168a1d#usage-pattern-for-a-proposed-new-es6-constructor-semantics) for constructors that don't just do the default ordinary allocation.
 
+It also, reduces the difference (and refactoring expense) between constructors common constructor patterns and constructors that do special allocation steps:
+
+Typically a constructor might look like this:
+```js
+   constructor(a,b) {
+      this = new super();
+      this.a = a;
+      this.b = b;
+   }
+```
+But without #3, a constructor that does special allocation might look like:
+```js
+   constructor(a,b) {
+      let newObj = this^.specialAllocationMethod();
+      newObj.a = a;
+      newObj.b = b;
+      return newObj.
+   }
+```
+With #3 this can be expressed as:
+```js
+   constructor(a,b) {
+      this = this^.specialAllocationMethod();
+      this.a = a;
+      this.b = b;
+   }
+```
+Only the **this** assignment is differnt from the typical construtor pattern.
+
+      
+
+
+
+
 
 
diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -38,6 +38,49 @@ e.g. using `new C(...args)`:
 
 The main innovation present at the meeting was the introduction of a new syntactic token `new*` that can be used to distigish a [[Constructor]] initiated evaluation of a constructor from a [[Call]] initialed evaluation. 
 
-Subsequent to this meaning we refined and polished the design.  What follows is the rationale for various changes that we made.
+Subsequent to this meaning we refined and polished the design.  In addition to changing `new*` to `new^` there we made three major changes:
+
+1  Using 'new super()' rather than 'super()' as the invocation of the super constructor via [[Construct]]
+2  Requiring an explicit "this=" rather than making the first super() call implicitly assign to this.
+3  Allowing anything to be assigned to "this" when it is in its TDZ of its constructor.
+
+###Rational for change #1
+Consider a constructor such as: 
+```js
+class D extends B {
+   constructor () {
+      If (!this^) super();
+      if (Math.random() >0.5) super();
+      f(super());
+   }
+}
+```
+Which of the `super()` expressions will do [[Construct]] invocation and which will do [[Call]] invocation? How does it change if the code is refactored? What happens if a *new* is put in front of any of the above `super()` expressions? Does it change the semanitics of any, some, or all of them?
+
+We already have enough confusions between "called as a function" and "called as a constructor".  A part of this proposal, for the first time, ECMAScript will allow a constructor to dynamically determine which way it was called.  In general `x()` means invoke via [[Call]] and `new x()` means invoke via [[Construct]].  It would terrible to further confuse things by introducing special situations where `super()` means [[Construct]] and not [[Call]].  If the ES programmer is thinking I need to invoke my base constructor, then `new super()`, is exactly the appropiate idiom and the right way to think about it.  Other languages that use `super()` for this purpose don't have the language level distinction between [[Call]] and [[Construct]].
+
+###Rational for change #2
+
+As discussed at the July meeting, `super()`, would magically bind **this** if it occurs in the **this** TDZ.  I say less magic, and no hidden implicit binding.  The intent of explicitly setting **this** is much clearer then `super()` which might might or might not set **this** (or be a [[Call]] or [[Construct]] depending upon what has already happened in the method.
+
+Changes #1 and #2 fit naturally together.  Where in previous designs we expected programmer to know the magic and say" 
+```js
+   constructor() {
+      super();  //looks like a [[Call]] acts as a [[Cponstruct]] and sets this
+      this.newProp = ...
+   }
+```
+we now expect to be explicit about their intent by saying:
+```js
+   constructor() {
+      this:= new super();  //always a [[Construct]], explicitly binds ths
+      this.newProp = ...
+   }
+```
+No magic, everything is explicit. 
+
+###Rational for change #3
+Once you have #2, #3 naturally follows and as we've shown there are [lots of use cases](https://gist.github.com/allenwb/53927e46b31564168a1d#usage-pattern-for-a-proposed-new-es6-constructor-semantics) for constructors that don't just do the default ordinary allocation.
+
+
 
-####Replace `super( )` with `new super()` to [[Construct]] invoke superclass constuctor
diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -40,4 +40,4 @@ The main innovation present at the meeting was the introduction of a new syntact
 
 Subsequent to this meaning we refined and polished the design.  What follows is the rationale for various changes that we made.
 
-##Replace``super( )` with `new super()` to [[Construct]] invoke superclass constuctor
+####Replace `super( )` with `new super()` to [[Construct]] invoke superclass constuctor
diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -36,3 +36,8 @@ e.g. using `new C(...args)`:
 >3.  During phase /* 3 */, the this-binding is initialised, and any call to a 
    super-method has the normal semantics of method (not constructor).
 
+The main innovation present at the meeting was the introduction of a new syntactic token `new*` that can be used to distigish a [[Constructor]] initiated evaluation of a constructor from a [[Call]] initialed evaluation. 
+
+Subsequent to this meaning we refined and polished the design.  What follows is the rationale for various changes that we made.
+
+##Replace``super( )` with `new super()` to [[Construct]] invoke superclass constuctor
diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -25,9 +25,9 @@ e.g. using `new C(...args)`:
    super-method call) will in fact invoke it with the semantics of a
    constructor, and will initialise the this-binding. It is somewhat 
    as if doing,
->
+>```js
 >      this = new super(...whatever)
-
+>```
 >   except that the default prototype of the created object will be
    `D.prototype` rather than `super.prototype`, where `D` is the constructor
    on which the `new` operator was originally applied (the reference to `D`

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -1,11 +1,11 @@
 At the July 2014 TC39 meeting, we presented a sketch of a new object instantiation design that was inspired from posting of Claude Pache. Here's the basic idea, as originally described by Claude:
 
 >If a constructor `C` uses `super` in its code, let’s say:
->
+>```js
 >   class C extends B {
 >       constructor(...args) {
 >           /* 1: preliminary code that doesn't contain calls to a super-method */
->          // ...
+>           // ...
 >
 >           /* 2: call to a super-constructor */
 >           super(...whatever)
@@ -14,7 +14,7 @@ At the July 2014 TC39 meeting, we presented a sketch of a new object instantiati
 >          // ...
 >       }
 >   }
->
+>```
 >the following occurs when `C` is invoked as constructor, 
 e.g. using `new C(...args)`:
 

diff --git a/new instantation rationale.md b/new instantation rationale.md
@@ -0,0 +1,38 @@
+At the July 2014 TC39 meeting, we presented a sketch of a new object instantiation design that was inspired from posting of Claude Pache. Here's the basic idea, as originally described by Claude:
+
+>If a constructor `C` uses `super` in its code, let’s say:
+>
+>   class C extends B {
+>       constructor(...args) {
+>           /* 1: preliminary code that doesn't contain calls to a super-method */
+>          // ...
+>
+>           /* 2: call to a super-constructor */
+>           super(...whatever)
+>
+>           /* 3: the rest of the code */
+>          // ...
+>       }
+>   }
+>
+>the following occurs when `C` is invoked as constructor, 
+e.g. using `new C(...args)`:
+
+>1.  During phase /* 1 */, the this-binding is uninitialised; trying to access 
+   it through an explicit `this` keyword will throw a ReferenceError.
+
+>2.  At phase /* 2 */, a call to the super-constructor (or, indeed, any
+   super-method call) will in fact invoke it with the semantics of a
+   constructor, and will initialise the this-binding. It is somewhat 
+   as if doing,
+>
+>      this = new super(...whatever)
+
+>   except that the default prototype of the created object will be
+   `D.prototype` rather than `super.prototype`, where `D` is the constructor
+   on which the `new` operator was originally applied (the reference to `D`
+   being forwarded by the super-call as needed).
+
+>3.  During phase /* 3 */, the this-binding is initialised, and any call to a 
+   super-method has the normal semantics of method (not constructor).
+
No results found