The particular example with `extends` doesn't matter much. What I manna do is those function out of the box to be able to extend an object with multiple objects at once. The example with class extends was just a recent practical use-case after Allen said no mixins for classes.
If (for whatever mystic reason, which I still would appreciate to be explained) people here don't like multiple args, the second arg in an alternative/worth case could be an array which contains several objects. But I personally wouldn't like it. There is no much need in showing me fancy cool examples with `reduce` -- I perfectly know and understand how it can be applied/abstracted later at user-level. The question is again to have it for users out of the box and design good APIs for end-users not bothering them to do this job for us. Currently these exact two methods are not a hi-pri, I believe there are more important things to discuss, but still those two would be great to reconsider. Dmitry On Wed, May 22, 2013 at 8:35 PM, Andrea Giammarchi < [email protected]> wrote: > Sorry but > > `class B extends Object.mixing(Mixin1, Mixin2, Mixin3...)` > > does not make sense to me ... would you mind explaining that ? > > I am curious about this "need to have more args there" since nowadays > there are many ways to simulate that and `String.fromCharCode`, as example, > demonstrated already that "unlimited number of args" is a lost for everyone > (reaching platform limit in terms of integers, memory, etc, at once) > > > On Wed, May 22, 2013 at 8:29 PM, Dmitry Soshnikov < > [email protected]> wrote: > >> OK, I had feeling that I already asked this before, and it is true, more >> than half and year ago: >> https://mail.mozilla.org/pipermail/es-discuss/2012-October/025929.html. >> This is why I was under impression that it was accepted and the methods >> should use multiple args. I completely forgot about it. And again, I can >> see this "mystic descriptors map" mentioned as a "reason", which clearly >> ins't the reason. >> >> By analyzing recent draft I was surprised not seeing multiple args for >> the mentioned methods which caused me to write this mail. >> >> I still would love seeing it corrected in the spec and standardized this >> way (which allows doing things like: class B extends Object.mixing(Mixin1, >> Mixin2, Mixin3...), which of course is not the best and even ugly way in >> contrast with "use" for mixins I mentioned, but -- anyways, this is >> different question; since we're not gonna have class-mixins, which is flow >> IMO, it's acceptable approach). >> >> Dmitry >> >> >> On Wed, May 22, 2013 at 6:26 PM, Dmitry Soshnikov < >> [email protected]> wrote: >> >>> OK. Sorry, you still haven't convinced me yet. >>> >>> Could someone from the committee explain me the real reasons please? If >>> I see them, I'm OK with having only one source. If there are good reasons, >>> I think we should use multiple sources with all advantages, which includes >>> also reflecting current libs APIs. >>> >>> Dmitry >>> >>> >>> On Wed, May 22, 2013 at 6:17 PM, Rick Waldron <[email protected]>wrote: >>> >>>> >>>> >>>> >>>> On Wed, May 22, 2013 at 9:10 PM, Dmitry Soshnikov < >>>> [email protected]> wrote: >>>> >>>>> Sorry, I didn't get it. Could you show an example of how it's >>>>> potentially can be used, I'm curious. If there is no practical need for >>>>> this -- of course it matters whether it worth or not. >>>>> >>>>> Since the spec is not approve yet, and particularly that section on >>>>> assign and mixin, it's exactly now a good time to (re)consider it. Since >>>>> if >>>>> no mixins will be available for class-syntax (as mentioned by Allen >>>>> recently), I at least want to see Object.mixin(...) accepting several >>>>> arguments in order to pass to a class' extends expression. >>>>> >>>> >>>> >>>> You're missing the point. The *possible* third argument is only a >>>> *possibility*. The one target, one source design is the _only_ form that >>>> will get committee consensus. >>>> >>>> >>>> Rick >>>> >>> >>> >> >> _______________________________________________ >> 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
