new instantiation design alternatives

Kevin Smith zenparsing at
Mon Sep 15 12:06:49 PDT 2014

> Because, if it is in the parameter scope, rather than the body scope then
> Kevin's "gimmeSomeComplexSuperArgsYo" function can't be an inner function
> of the constructor.  It has to be an unencapsualted function outside of the
> class definition.

No different than default expressions, right?  We got rid of hoisting body
declarations above them, if I remember correctly.

But feel free to propose and champion a complete alternative proposal that
> address all aspects of object instantiation design. That's probably a
> better approach than trying to incrementally change details of a coherent
> design until it is something completely different.

Let my share my perspective here.

The @@create design was very simple and elegant, and as far as I know there
were no serious objections, except...

Built-ins don't want separation of allocation from initialization.  In
Jason's thread, I asked why we couldn't just add the constructor params to
the "@@create" function, but realized that wouldn't work because it would
require most subclasses to implement both a constructor and an "@@create"
(in order to remap the constructor args).

After seeing this thread, I realized that you could, in fact, fix
"@@create" by simply moving the underlying concept to the constructor head.
 That allows the user to remap constructor args without having to
reimplement two separate methods.

In my opinion, this approach preserves everything that we like about the
previous approach while fixing the known issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list