new instantiation design alternatives
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss