new instantiation design alternatives

Domenic Denicola domenic at domenicdenicola.com
Wed Sep 17 07:21:38 PDT 2014



On Sep 17, 2014, at 7:10, "Kevin Smith" <zenparsing at gmail.com<mailto:zenparsing at gmail.com>> wrote:


That seems fine. Enabling different behaviour for called vs. constructed should only be used to explain the builtins; user code should not do so themselves. So it makes sense to me that those trying to do that would get "punished" with having to type more.


Yes, but if we guide users toward "this = new super", we actually change the current paradigm where the constructors can be called or new'd.

As an example, this:

    function C() { B.call(this) }

functions perfectly well as an object initializer, with or without "new".

That's not true, is it? Assuming someone (e.g. B) actually assigns a property of `this`, an error will occur (or worse, a global will be created, in sloppy mode).

Constructors can be called or newed today only if you insert the error-prone incantation `if (!(this instanceof C)) { return new C(...arguments); }`, but now we're back to paying a cost.

In short, I see no shift from today's semantics.

But this:

    class C extends B { constructor() { this = new super() } }

does not.  It throws if you attempt to use it as an initializer without "new".

(This is also somewhat of an issue for the extended header approach.)

Do we want to shift the paradigm?  Part of the design goal for classes was that we didn't want to shift any paradigms.  That's what I need more time to think about.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140917/1a6bbfce/attachment.html>


More information about the es-discuss mailing list