new instantiation design alternatives

Claude Pache claude.pache at gmail.com
Wed Sep 17 07:29:05 PDT 2014


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, 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. 

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.

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.

One may propose an additional implicit-super-call feature, if it solves a particular issue. Or propose a new design where such a feature plays a central role in resolving the original issue. But it should be justified and discussed separately to avoid confusion.

—Claude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140917/064c7c9a/attachment.html>


More information about the es-discuss mailing list