Duplicate super call behaviour

Allen Wirfs-Brock allen at wirfs-brock.com
Sun Oct 25 19:15:58 UTC 2015


> On Oct 24, 2015, at 5:45 PM, Mark S. Miller <erights at google.com> wrote:
> 
> 
> 
> On Sat, Oct 24, 2015 at 8:00 PM, Sebastian McKenzie <sebmck at gmail.com <mailto:sebmck at gmail.com>> wrote:
...

> But this check is performed at step 10 whereas the super constructor is actually evaluated at step 7.
> 
> Is my reading correct? If so, to me this behaviour seems quite unexpected.
> 
> I'm surprised. Good catch! Frankly, this case had never occurred to me and I do not remember discussing it. I would certainly prefer that it be an error without constructing twice.
> 
> 
>  
> 
> Any insight (or correction) is extremely appreciated, thank you!

Sebastian, you reading is correct.

Mark, I’m pretty sure that I brought attention to this in some venue and there was agreement that the possibility of observable side-effects with post call error check really didn’t matter as long as implementations concisely followed the spec. and all did it that way.

But, I agree that pre-check seems more intuitive. I think it ended of this way largely because within the spec. the check for attempting to rebind this only occurs within the  BindThisValue abstract operation.  So doing the post call check was the easier think to specify (and we were working against the clock at that time).  To do a pre-check we’d have to add an additional internal method to FunctionEnviornmentRecord (and probably also replace the check in  BindThisValue with an assertion).

Such a change for ES2016 seems reasonable to me.

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


More information about the es-discuss mailing list