Default call constructor behavior
Le 26 oct. 2015 à 03:59, Isiah Meadows <isiahmeadows at gmail.com> a écrit :
According to the current call constructor proposal, the behavior for classes without call constructors is to unconditionally throw. Shouldn't this be changed to automatically calling the constructor? I see this as better for several reasons:
- It's consistent with most of the builtins, including all of the new ES6 types.
No, new builtins are specced to protest when you forget new (except for Symbol where it is the other way round).
- It's easier to integrate into several libraries. I've run into a ton of issues with trying to add support for ES6 classes in a specific library written for ES5 for this reason. I can use
C.apply(null, args)instead ofnew (Function.apply(C.bind, [null].concat(args)))().
You should use Reflect.construct() or a shim for it, here.
Also, note that the expectation that Foo(...args) is equivalent to new Foo(...args) doesn’t stand for user-defined pre-ES6 constructors unless they include specific boilerplate. So, anyway, you or the library you’re using should not make such an assumption when working with constructors they don’t own. For constructors they own, the call constructor proposal will make easy to opt-in for that feature.
- It's easier to use in functional programming. (
titles.map(Book)instead oftitles.map(title => new Book(title)))
Fair. But your Book constructor should be explicitly documented that it does the same thing when called as when constructed, since that pattern won’t work with all classes. And if the documentation should be explicit, so should be the implementation.
- It's easier to partially apply. It would make the implementation of the proposed Function.prototype.partial very easy, as well as simplify and speed up Function.prototype.bind for classes, as assumptions can be made.
Function.prototype.partial might be simplified under the assumption that Foo(...args) is equivalent to new Foo(...args), but you can’t make that assumption in the general case, so you have to implement it the "complicated" way anyway. The only potential advantage is that it may be easier for engines to detect when it is possible to do a specific optimisation.
Since this thread seems to be taking F.p.partial seriously, as a possible future spec to take into account, I should clarify that I never saw an argument for it I found compelling. If anyone active on the committee feels otherwise or is thinking about championing it, please speak up. Otherwise, I would not worry about this being in our future.
If it should gain widespread use as a user-written library function, then of course we should reconsider. Its advocates should try that approach first and see how far it gets. After all, that's where F.p.bind came from.
I was using F.p.partial as merely an example. There are others I could have
used. The main problem related to 4 is applying a constructor without
needing to bind it.
I rarely have the use case for F.p.partial myself, unless I'm experimenting with point free style (which is admittedly not very idiomatic JS).
A downside of specifying a default like this is that adding a "call constructor" (can we think of a better name for this?) to an existing class would become a breaking change for users of that class.
According to the current call constructor proposal, the behavior for classes without call constructors is to unconditionally throw. Shouldn't this be changed to automatically calling the constructor? I see this as better for several reasons:
It's consistent with most of the builtins, including all of the new ES6 types.
It's easier to integrate into several libraries. I've run into a ton of issues with trying to add support for ES6 classes in a specific library written for ES5 for this reason. I can use
C.apply(null, args)instead ofnew (Function.apply(C.bind, [null].concat(args)))().It's easier to use in functional programming. (
titles.map(Book)instead oftitles.map(title => new Book(title)))It's easier to partially apply. It would make the implementation of the proposed Function.prototype.partial very easy, as well as simplify and speed up Function.prototype.bind for classes, as assumptions can be made.