new instantiation design alternatives

Kevin Smith zenparsing at gmail.com
Wed Sep 17 07:10:33 PDT 2014


>
>
>  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".

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/cf8f892c/attachment.html>


More information about the es-discuss mailing list