On Sep 17, 2014, at 7:10, "Kevin Smith"
<zenpars...@gmail.com<mailto:zenpars...@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.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
