17.09.2014, 18:10, "Kevin Smith" <zenpars...@gmail.com>:
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".
In ES5 it's not valid, because if B returns object, this thing will fail to initialize anything.
I think the correct function is this one: `function C() { var self = new B(); Object.setPrototypeOf(self, C.prototype); return self; }` if B isn't a part of your own codebase.
Note that `var self = new B()` and `this = new super()` are very close to each other, so we're going the right way here, making that somewhat a standard.
,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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
