We did discuss return expr; in constructors at the TC39 meeting, and my
sense is that we want to keep that option. Classes as sugar (mostly),
and all that.
/be
Claude Pache <mailto:[email protected]>
February 3, 2014 at 11:09 AM
I don't see much advantage in being allowed to write `return
someExpressionThatShouldYieldUndefined`. Indeed, you can always write
`someExpressionThatShouldYieldUndefined; return`, or even: `if
(someExpressionThatShouldYieldUndefined !== undefined) throw new
TypeError; return`.
Also, the problem, with runtime exception, is that we are no longer
able to easily differentiate between `construct` methods that are
defined using the `class` syntax and other `construct` methods...
which raise the issue of backward compatibility.
—Claude
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Brandon Benvie <mailto:[email protected]>
February 3, 2014 at 10:39 AM
I like the motivation, but doing it as an early error is problematic
(having experienced a validator that differentiates between `return`,
`return undefined`, and `return void expr` and complains loudly).
Instead I would suggest to throw an error at runtime if a class
constructor returns anything besides undefined when it is constructed.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Claude Pache <mailto:[email protected]>
February 3, 2014 at 10:22 AM
I think that this bug is indeed a good reason to use
`super(...arguments)` instead of `return super(...arguments)`.
However, I am slightly worried that, with the ES6 class syntax, the
`constructor` method looks like a regular method, but it behaves
differently w.r.t. inheritance. So, nonstandard uses of this method
(wmay mysteriously fail when used on a super-class.
Therefore, it would be nice if `return expression` would be statically
forbidden in the `constructor` method when defined using the `class`
syntax (but a bare `return` is fine, which slightly complicates the
grammar).
—Claude
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock <mailto:[email protected]>
February 2, 2014 at 2:27 PM
I made the change in rev 22 to make the default constructor: return
super(...args)
However that resulted in this bug:
https://bugs.ecmascript.org/show_bug.cgi?id=2491 from Arv:
I'm inclined to agree with Arv's conclusion. What do you think?
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock <mailto:[email protected]>
December 28, 2013 at 11:11 AM
Plausible, but what about the possibility that a framework
dynamically patches the prototype chain of C.prototype before it is
first instantiated or if C uses its @@create method to return
instances that have different or extra objects (that have a
'constructor' property) patched into their prototype chain.
This, like the base question of this thread, seems like another
example of a tension between supporting the "normal" usage patterns
for class declarations and allowing enough flexibility to enable using
class declarations as building blocks for less normal abstractions.
I could probably go either way. Pragmatically, from a spec. writing
perspective, the conditions for issuing this error are bit complicated
to define. Even without an extends clause the instances still inherit
from Object.prototype so super call still need to be allowed in
non-constructor instances methods and even in constructor methods
things like super.toString() need to be allowed. I generally try to
avoid early errors that have a lot of conditions associated with them.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
