Object.mixin/Object.assing with multiple args
On Wed, May 22, 2013 at 7:48 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote:
Hello,
It's very likely it was (should have been I believe) discussed before, and even probably was approved, but I don't see it in the latest draft yet.
The following has been discussed, but...
Just to make sure, the signature of the "assign" and "mixin" method should be:
Object.assign(target, source,[source2, ..., sourceN]); Object.mixin(target, source,[source2, ..., sourceN]);
Current draft shows me only one source for both the methods.
That's correct. The third argument is being reserved for a descriptor map (potentially). Object.assign is not specified to match the exact behaviour of any existing object "merge", "extend", "mixin" operation.
This is not unreasonable:
function merge(target, ...sources) { return sources.reduce(Object.assign, target); }
On Wed, May 22, 2013 at 5:53 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
On Wed, May 22, 2013 at 7:48 PM, Dmitry Soshnikov < dmitry.soshnikov at gmail.com> wrote:
Hello,
It's very likely it was (should have been I believe) discussed before, and even probably was approved, but I don't see it in the latest draft yet.
The following has been discussed, but...
Just to make sure, the signature of the "assign" and "mixin" method should be:
Object.assign(target, source,[source2, ..., sourceN]); Object.mixin(target, source,[source2, ..., sourceN]);
Current draft shows me only one source for both the methods.
That's correct. The third argument is being reserved for a descriptor map (potentially). Object.assign is not specified to match the exact behaviour of any existing object "merge", "extend", "mixin" operation.
OK, good to know. Can you show a practical example with this (potential) descriptor map argument? Just wanna make sure it's really more useful than accepting multiple sources.
This is not unreasonable:
function merge(target, ...sources) { return sources.reduce(Object.assign, target); }
Sure. The question is not that we can write own abstraction on top of existing behavior, the question is having it out of the box. Unless the descriptor map you mention really worth it.
Dmitry
On Wed, May 22, 2013 at 9:00 PM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:
Sure. The question is not that we can write own abstraction on top of existing behavior, the question is having it out of the box. Unless the descriptor map you mention really worth it.
Doesn't matter if you or I think the descriptor map is "really worth it", when I pushed for these, part of the consensus hinged on one target, one source.
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.
Dmitry
I think [mixin1, mixin2, mixin3].reduce(Object.mixin, source); is a win,
only thing I am not sure, is how this third argument could make into this
approach (if reusable, I didn't even know about this extra arg)
Any hint on the extra arg appreciated for polyfill purpose,
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.
Please hold on with pollyfilling, until we realize this is something is really required and can be useful. If it's not, this should be changed to multiple arguments. Since this "potential" map is not even in current draft, I believe Rick refers to something that was never taken as a real thing to apply.
Dmitry
I never hold on on polyfills, I already use Object.mixin in redefine.js and other personal code ;-)
I think the direction is that second argument to N extra is an old pattern TC39 won't lie for any new API
TC39 won't lie => TC39 won't like
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
OK, I had feeling that I already asked this before, and it is true, more than half and year ago: esdiscuss/2012-October/025929. 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
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)
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
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.
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.
Andrea, I see what you're saying. And yes, for some fluent function signature which very likely can be changed in the future, of course reserving additional parameter spots makes sense (although, of course too many explicit function arguments is a bad design also -- but this "infinite" number of args shouldn't be confused with "too many explicit" args; the former makes perfect sense to me in functions like "printf", console.log or Object.mixin -- these functions are stuck with their signature -- they accept variant number of args, and this is exactly the convenience).
I always glad to revisit my viewpoint of course. And again, for this I'd appreciate (and yeah, still not loosing the hope for) a small amount of time explaining the reasons behind this, which was the actual consensus as I'm told.
Dmitry
It's very likely it was (should have been I believe) discussed before, and even probably was approved, but I don't see it in the latest draft yet.
Just to make sure, the signature of the "assign" and "mixin" method should be:
Object.assign(target, source,[source2, ..., sourceN]); Object.mixin(target, source,[source2, ..., sourceN]);Current draft shows me only one source for both the methods.