new instantiation design alternatives

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Sep 17 11:27:36 PDT 2014


On Sep 17, 2014, at 7:29 AM, Claude Pache wrote:

> 
> Le 11 sept. 2014 à 18:35, Allen Wirfs-Brock <allen at wirfs-brock.com> a écrit :
> 
>> 
>> 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. 
>> 
> 
> 
> The following is probably apparent from the present thread, but I think it should be stated clearly.
> 
> A big problem with those proposals, is that they add a semantic change, namely implicit super-constructor calls aka the automatic allocation feature,

only the first alternative.  They second does not do implicit allocations or super-constructor calls. This is the primary difference between the two alternatives that were present.


> which is neither part of the currently specced design (the one with @@create), nor contributes to solve the particular problem that lead to the redesign (observability of allocated but uninitialised built-ins/DOM objects), nor (unless I missed something) is properly justified in the Gists. 

the @@create design in does implicit allocation. It does so by the ordinary [[Construct]] calling @@create which is responsible for doing allocation ([[Construct]] is even specified with a fall back allocation if @@crete doesn't exist).  ES `new` has always done "implicit allocation" within [[Construct]] and the primary purpose of constructor bodies has been to initialize the implicitly allocated object.

Auto-super constructor calls a a separable issue and don't appear in alternative #2.

The motivation was simplifcation of what we believed to be the most common use case:

class D extends B {
   constructor (b,c) {
         this.c = c;   //no need for an explicit super call
    }
}

alternative #2 requires an explicit super call for this use case:

class D extends B {
   constructor (b,c) {
         this = new super(b);
         this.c = c;   //no need for an explicit super call
    }
}

That's the difference.
> 
> Those implicit super-constructor calls might make sense, but they also introduce traps (e.g., spurious super calls in case of incorrect use, as found in Section "Some AntiPatterms" [sic] of the Gists), and need therefore be carefully considered before being introduced.

Hence the emergence of alternative #2 (and also the Domenic variation)

> 
> My advice is to modify the proposal, removing entirely that novel feature (as Domenic said: if `this = ...` is absent, just do an implicit `this = Object.create(new^.prototype)`), and focusing to tackle only the issue that was intended to be solved. It would remove much distraction in the discussion.

There are already good arguments for alternative #2, among them is that it eliminates the significant dead-code issue that was discovered here. The Domenic variation is plausible although it still has the dead code issue is tied to `this=` presence and (I think) has a few more error hazards if not. 

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140917/9d042cee/attachment-0001.html>


More information about the es-discuss mailing list