<div dir="ltr">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.<div><br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 26, 2015 at 8:49 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p>
<p dir="ltr">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). </p>
<br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 26, 2015, 06:22 Mark S. Miller <<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 26, 2015 at 4:35 AM, Claude Pache <span dir="ltr"><<a href="mailto:claude.pache@gmail.com" target="_blank">claude.pache@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> Le 26 oct. 2015 à 03:59, Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> a écrit :<br>
><br>
> According to the current call constructor proposal, the behavior for<br>
> classes without call constructors is to unconditionally throw.<br>
> Shouldn't this be changed to automatically calling the constructor? I<br>
> see this as better for several reasons:<br>
><br>
> 1. It's consistent with most of the builtins, including all of the new<br>
> ES6 types.<br>
<br>
</span>No, new builtins are specced to protest when you forget `new` (except for `Symbol` where it is the other way round).<br>
<span><br>
> 2. It's easier to integrate into several libraries. I've run into a<br>
> ton of issues with trying to add support for ES6 classes in a specific<br>
> library written for ES5 for this reason. I can use `C.apply(null,<br>
> args)` instead of `new (Function.apply(C.bind,<br>
> [null].concat(args)))()`.<br>
<br>
</span>You should use `Reflect.construct()` or a shim for it, here.<br>
<br>
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.<br>
<span><br>
> 3. It's easier to use in functional programming. (`titles.map(Book)`<br>
> instead of `titles.map(title => new Book(title))`)<br>
<br>
</span>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.<br>
<span><br>
> 4. It's easier to partially apply. It would make the implementation of<br>
> the proposed Function.prototype.partial very easy, as well as simplify<br>
> and speed up Function.prototype.bind for classes, as assumptions can<br>
> be made.<br>
<br>
</span>`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.<br>
<span><font color="#888888"><br>
—Claude<br>
</font></span><div><div><br>
><br>
> --<br>
> Isiah Meadows<br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div>    Cheers,<br>    --MarkM</div>
</div></blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>