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.
On Mon, Oct 26, 2015 at 8:49 AM Isiah Meadows <[email protected]> wrote: > I was using F.p.partial as merely an example. There are others I could > have used. The main problem related to 4 is `apply`ing 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). > > On Mon, Oct 26, 2015, 06:22 Mark S. Miller <[email protected]> wrote: > >> 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. >> >> >> >> >> On Mon, Oct 26, 2015 at 4:35 AM, Claude Pache <[email protected]> >> wrote: >> >>> >>> > Le 26 oct. 2015 à 03:59, Isiah Meadows <[email protected]> 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: >>> > >>> > 1. 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). >>> >>> > 2. 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 of `new (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. >>> >>> > 3. It's easier to use in functional programming. (`titles.map(Book)` >>> > instead of `titles.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. >>> >>> > 4. 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. >>> >>> —Claude >>> >>> > >>> > -- >>> > Isiah Meadows >>> > _______________________________________________ >>> > 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 >>> >> >> >> >> -- >> Cheers, >> --MarkM >> > _______________________________________________ > 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
