Ok I stand corrected -- I didn't think to consider that returning
undefined is the same as not returning.
On 12/24/13, 11:02 PM, Jeff Morrison wrote:
You mean return-if-undefined, right? Not sure if that adds a dimension
of oddity to the idea that might change your mind.
(Obviously I'm not a fan of returning from constructors in the first
place -- but that's just because I think it's generally a code smell.
People do it even if I don't)
-Jeff
On 12/24/13, 8:41 PM, Sebastian Markbåge wrote:
This is an esoteric and ugly use case but I'm not trolling. The
default constructor for a class which extends another is:
constructor(...args){ super(...args); }
Is there any reason it shouldn't return the value from super?
constructor(...args){ return super(...args); }
Basic constructors still have the quirky behavior of ES functions
that they can return any object and don't have to return the
instantiated object. This can be useful if they're used as functions
or should return a placeholder object, or other instance, for
compatibility/legacy reasons. E.g. when you have a custom
instantiation process.
class Foo { constructor() { return {}; } }
Currently, this behavior doesn't carry over to subclasses by default:
class Bar extends Foo {}
You'd have to explicitly define a constructor that returns the value
from the super call.
Additionally, since DefineMethod is going to be exposed, does it make
sense to expose ReferencesSuper too?
Otherwise there is no way to detect, at runtime, if a default
constructor function is a top-level constructor (without a super), or
a subclass with a super. One of them can use toMethod but not the other.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
