new instantiation design alternatives

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Sep 12 08:34:12 PDT 2014


On Sep 12, 2014, at 8:01 AM, Kevin Smith wrote:

> 
> 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?)

actually the, it's the `this` passed to the @@create method.

> 
> "this=" is how you initialize the this object (previously the return value from @@create).
> 
> Allen, is that a fair run-down?

yes

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


More information about the es-discuss mailing list