@@new

[Dmitry Soshnikov]

On Tue, Jun 17, 2014 at 12:21 PM, Jason Orendorff <jason.orendorff at gmail.com
> wrote:
...

>
> ## Benefits
>
> *   As with Allen's proposal, we would drop [[Construct]] and the
> `construct`
>     trap.
>
> *   @@create can be dropped entirely, but we retain the benefit to
> implementers
>     that all Maps (for example) can have the same in-memory layout, and
> other
>     objects can't become Maps at runtime.
>
>
These are pure implementation details, and only implementation
improvements, that are not that interesting to actual developers.



>
>     This would reduce the number of `super` forms to these 3:
>
>         super.IdentifierName  // allowed in all methods
>         super[Expression]     // allowed in all methods
>         super(arguments)      // only allowed in constructors
>
>
I missed that: so we got another restriction, and devs won't be able to use
convenient concise `super()` calls from other methods? I don't think it's
the best direction.

Overall, we got three restrictions:

  (1) super only on top of the constructor,
  (2) want it or not: parent constructor is always called,
  (3) you can't use concise super calls from methods.
  + bonus (4) you have to use some verbose syntax of static [Symbol.new]()
{} to do needed hacks.

What all these for? To exclude [[Construct]]/@@create form the
implementation? But developers are not interested in the implementation.
Developers want to make convenient super-calls, do not call parent
constructors if it's not needed (yes, it's rare, but can be), or to call it
whenever they want after predefined prologue.

Personally I think two traps are more intuitive and convenient (and are
present in many other languages: C++, Ruby, etc) than this
"spec/implementation-optimization", and users would appreciate the `new`
and `constructor` traps. The former can be used in rare cases when they'll
need custom allocation (and `this` value is not available there yet), and
the `constructor` is a normal initialiser of the allocated instance.

I mean, there should be a very strong reason to change an intuitive
semantics to this approach. "Spec/implementation optimizations" is not the
best reason, and that "parent constructor should always be called" is a
subjective, and just one of the semantics.

P.S.: as for the libraries, some "libraries" (actually my tests) were also
coupled to this allocate/initialize pair hooks approach:
https://gist.github.com/DmitrySoshnikov/1367025#file-r-proto-class-class-js-L23-L41

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140618/6db2c5ff/attachment.html>