Dmitry I agree there's no need to underline fancy methods but you know an API is also good when you can do almost everything you want with few extra steps, right?
My example was poor too so I'll try to better explain my point of view, unaware of decisions made here or in some TC39 meeting I have not followed. A signature with multiple arguments is trapped forever because nothing else can be reasonably added after so it's everything but future proof and you have to be extra careful "these days" with things that make anything more useful impossible to implement if not creating a new method. I give you `Object.defineProperty` as example which has a multiple counterpart as `Object.defineProperties` In a better future, both might accept a third argument with defaults for properties descriptors so that same API can accept values, as example, instead of descriptors only (specially in the second case) You think no? Well, it's OK, we can discuss about that ... but if `Object.defineProperty` would have accepted the target object, one or more properties as key names and one or more related descriptors per each key, the discussion would never exist and even if useful the method won't be mutated in something else anymore. I believe the direction is named arguments, in terms of object properties, against ordered properties, where the distinction could be in terms of different objects as parameters, instead of different sequence of arguments, which is more limited. For consistency, I would prefere a single model and if this is one target, and one property parameter, as preferred choice, rather than one target, and who knows how many parameters after. Last, but not least, I am simply speaking out my mind against your arguments but I've no idea if anything I've said has a concrete coutnerpart in TC39 take on this so ... just in case you would like to revisit your point of view or consider some extra reason to prefer a prefixed amount of well known, and more powerful, arguments. Sorry for any confusion on my personal thoughts over this matter. Regards On Wed, May 22, 2013 at 8:59 PM, Dmitry Soshnikov < dmitry.soshni...@gmail.com> wrote: > 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 < > andrea.giammar...@gmail.com> 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 < >> dmitry.soshni...@gmail.com> 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 < >>> dmitry.soshni...@gmail.com> 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 >>>> <waldron.r...@gmail.com>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, May 22, 2013 at 9:10 PM, Dmitry Soshnikov < >>>>> dmitry.soshni...@gmail.com> 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 >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
