Le 11 sept. 2014 à 18:35, Allen Wirfs-Brock <al...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to