new instantiation design alternatives

Axel Rauschmayer axel at rauschma.de
Wed Sep 17 05:18:31 PDT 2014


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 <allen at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-- 
Dr. Axel Rauschmayer
axel at rauschma.de
rauschma.de



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


More information about the es-discuss mailing list