new instantiation design alternatives

Jeff Morrison lbljeffmo at gmail.com
Thu Sep 11 23:39:34 PDT 2014


" If a constructor body contains an assignment of the form*this**=*then 
automatic allocation is not performed and the constructor is expected to 
perform manual allocation."
If I'm understanding this correctly, this means that snippet (A) would 
never have access to `this`, but snippet (B) would have an implicit 
`this` binding -- is that correct?

(A)
```
class Foo extends Bar {
constructor() {
     if (false) {
       this = super();
     }
     this; // undefined
   }
}
```

(B)
```
class Foo extends Bar {
constructor() {
     // No call to `this =` present in the constructor
     this; // the automatically allocated object -- i.e. this !== undefined
   }
}
```

If this is the case, it occurs to me that it would raise issues for 
things like automated refactoring and/or dead code elimination (as a 
minifier might do).
Normally a minifier (or even a human) would expect to be able to 
eliminate the entire conditional altogether if they were confident the 
condition never evaluated to true. But with this static pre-check acting 
as the indicator for whether automatic allocation/binding should happen, 
doing so would cause the constructor to act very unexpectedly 
differently in the two cases.

I wish I could suggest an alternative, but nothing comes to mind right now.

Thoughts?

-Jeff

On 9/11/14, 12:35 PM, Allen Wirfs-Brock wrote:
> At the last TC39 meeting ( 
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#44-instantiation-reform-review-create-design-rationale-and-possible-alternatives 
> <https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md> and 
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-31.md#44-follow-up-instantiation-reform-create ) 
> we agreed to a general direction to try for a new object instantiation 
> design to replace @@create.
>
> Since then I have gotten feedback and had design discussions with a 
> number of individuals. This has lead to a number of refinements of the 
> core design and one remaining point where there are strong contrary 
> positions. The point of contention is about whether or not a subclass 
> construction ever implicitly calls its superclass constructor.
>
> https://gist.github.com/allenwb/291035fbf910eab8e9a6  summaries the 
>  main syntactic changes since the meeting and provides rationales 
> them. These features are common  to both alternates.  this is a good 
> place to start, after reading the meeting notes.
>
> I have prepared two longer Gists that outline the two alternatives 
> designs, presents design rationales,  and provides usage examples for 
> a number of likely use cases. Note that  there is more commonalities 
> then differences among the two alternatives.  the syntactic choices 
> and semantics of [[Construct]] are the same for both.
>
> These two Gist have parallel construction for easy comparison. I 
> suggest approaching this is by first readying through one of the Gists 
> and then doing a side by side read through of the alternative to see 
> the differences in the designs and usage.
>
> https://gist.github.com/allenwb/5160d109e33db8253b62 with implicit 
> super construct if no local allocation
> https://gist.github.com/allenwb/53927e46b31564168a1d explicit super 
> construct required if no local allocation
>
> I appreciate it if major constructive feedback on any of these 
> documents were made via Gist comments.
>
> Allen
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140912/067fe256/attachment-0001.html>


More information about the es-discuss mailing list