new instantiation design alternatives

Kevin Smith zenparsing at
Fri Sep 12 08:01:20 PDT 2014

> Sorry to interject, but was the rationale for needing a new syntax for
> this (vs. an API-based solution) presented anywhere? I can't seem to find
> it.

Feel free to correct me here...

The current setup (with @@create) was designed to provide sugar for
ES5-style OOP.  As such, it separates allocation (the `new` part) from
initialization (the constructor part).  It's very elegant.

However, this appears to be unsatisfactory when subclassing built-in and
host-provided classes.  For those cases, we don't want to expose "allocated
but uninitialized" objects (e.g. DOM objects implemented in C++).  So
separating allocation from initialization is not desired for those cases.

This led us to the idea of setting the "this" value from within the
constructor itself, essentially fusing "constructor" and "@@create" into
one function.

"new^" is argument originally provided to @@create.  (Is that right?)

"this=" is how you initialize the this object (previously the return value
from @@create).

Allen, is that a fair run-down?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list