Object.mixin/Object.assing with multiple args

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Wed May 22 20:29:25 PDT 2013

OK, I had feeling that I already asked this before, and it is true, more
than half and year ago:
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).


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130522/1bab03e7/attachment.html>

More information about the es-discuss mailing list