" 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
