Object.mixin/Object.assing with multiple args

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Wed May 22 20:59:07 PDT 2013


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.giammarchi at 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.soshnikov at 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.soshnikov at 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.rick at gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, May 22, 2013 at 9:10 PM, Dmitry Soshnikov <
>>>> dmitry.soshnikov at 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 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/20130522/0dd91f11/attachment-0001.html>


More information about the es-discuss mailing list