I find the new suggestions hard to make sense of and the current approach quite elegant:
``` Foo[[Construct]](arg) ::= 1. let obj = Foo[@@create]() 2. Foo.call(obj, arg) ``` To me, it seems that this is how things should work internally, because that’s what’s actually going on. Is there no other way to fix the following two problems? For example: to fix #2, couldn’t we somehow prevent direct invocations? I also don’t fully understand what #1 means. 1. If instances aren't sufficiently initialized by @@create, then instance objects could leak (e.g. via a nefarious decoupling between the @@create allocation process and the constructor-function initialization process) 2. @@create could be called directly Observation about the new approach:: could the `if (new^) ...` check be turned into a method? Axel On 11 Sep 2014, at 18:35 , Allen Wirfs-Brock <al...@wirfs-brock.com> 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 > 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss