Object.mixin/Object.assing with multiple args

Matthew Robb matthewwrobb at gmail.com
Thu May 23 09:55:26 PDT 2013


I think I would rather not make the case of doing a bunch of fancy stuff in
the RHS of extends so that hopefully in the future we can "extend" the
class syntax to support some sort of propper mixin or trait scenario.

At first I thought maybe something like: class D extends A, B, C {  } but
this would imply real multiple inheritance rather than prototype mixing.
But there could still be something later on that goes in the body like the
"uses..." brought up earlier on.


On Wed, May 22, 2013 at 11:18 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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.soshnikov at 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.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
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
- Matthew Robb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130523/9a9c1545/attachment.html>


More information about the es-discuss mailing list