Default call constructor behavior

[Kevin Smith]

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 <isiahmeadows at gmail.com>
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 <erights at google.com> 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 <claude.pache at gmail.com>
>> wrote:
>>
>>>
>>> > 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:
>>> >
>>> > 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
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151026/1409bcec/attachment-0001.html>