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
