Object.mixin( source, target ) | arguments changed
A real brain-bender for all those "extend" workalike users.
LHS, RHS assignment-expression order is best (Moto 68K vs. Intel 808x asm wars; also gdb vs. binutils IIRC).
The lack of extensibility (or should we allow multiple sources now?) is the killer for me.
It seems es-discuss receives a lot of these emails, bikeshedding the behavior of Object.mixin from people with preconceived notions of what a "mixin" is and what a mixin function should do, how it should integrate with class syntax, etc. In contrast, when it was just Object.define, it was obscure enough nobody seemed to misinterpret it in such ways.
I'm not necessarily suggesting TC39 should switch the name just so that es-discuss stops getting these kind of emails... but maybe it's a sign that "mixin" is not the best choice.
The fact it has been proposed as "mixin" method is a sign too ... is like
saying that class in JS is wrong because classical inheritance meant in
other language is not exactly the same in JS.
It would be nice to focus on the signature and finalize that in the spec instead of raising every now and then some naming convention good for some and bad for others ... I mean, how comes here we ll knwo what we talk about when we say mixin ?
Just saying, my 2 cents.
On Thu, Jun 13, 2013 at 12:08 PM, Domenic Denicola < domenic at domenicdenicola.com> wrote:
It seems es-discuss receives a lot of these emails, bikeshedding the behavior of
Object.mixinfrom people with preconceived notions of what a "mixin" is and what a mixin function should do, how it should integrate with class syntax, etc. In contrast, when it was justObject.define, it was obscure enough nobody seemed to misinterpret it in such ways.I'm not necessarily suggesting TC39 should switch the name just so that es-discuss stops getting these kind of emails... but maybe it's a sign that "mixin" is not the best choice.
These points are all very valid and I'd be willing to champion a name change for these reasons.
On Thu, Jun 13, 2013 at 11:38 AM, Tobias Buschor <tobias.buschor at gmail.com>wrote:
I propose to change the arguments.
The second argument "target" is optional and default to "Object.create(null)"
This can already be achieved with Object.mixin(Object.create(null), source) or if you've imported the dict module (or dict from whatever module it lives in) Object.mixin(dict(), source)
The return-value is the modified target
This is already true.
Advantages:
- Without the second argument, we can copy the source
This can already be achieved with Object.mixin({}, source).
- It is more natural to say "mixin the source into the target" => misin.(source, target)
Subjectively, maybe? None of the existing cow-highways look like this.
Disadvantages
- Its not suitable to extend the function to accept multiple sources in the future
It also means that Object.assign's arguments would have to be flipped.
Based on this and the example shown above, I think it's fair to say that reversing the arguments isn't in the ES6's best interest.
Based on this and the example shown above, I think it's fair to say that reversing the arguments isn't in the ES6's best interest.
Definitely. Reversing the argument order would make for awkward code like this:
Object.mixin({
a() {},
b: 123,
c
}, target);
And I agree that we should attempt to find a different name for "mixin", if possible. (although it means I'll have to change my bleeding edge code yet again!)
While I like the name mixin, I infinitely like the name define more. Better still I LOVE this strawman:define_properties_operator
On Jun 13, 2013, at 10:09 AM, Kevin Smith wrote:
Based on this and the example shown above, I think it's fair to say that reversing the arguments isn't in the ES6's best interest.
Definitely. Reversing the argument order would make for awkward code like this:
Object.mixin({ a() {}, b: 123, c }, target);And I agree that we should attempt to find a different name for "mixin", if possible. (although it means I'll have to change my bleeding edge code yet again!)
We went through this once before and considered other names including "define" and "extend" and concluded that "mixin" has the fewest warts. I'm not sure how useful it is to revisit the names again.
I personally don't see that there is any real conflict between Object.mixin and a hypothetical "mixin" superclass combinator that someone might define in the future. They are distinct functions, that do different (but conceptually somewhat related) things. It's not obvious to me that Object.mixin would be any more of a source of confusion than "define", "extend", or any other English word that might also be used in other contexts.
Allen Wirfs-Brock wrote:
I personally don't see that there is any real conflict between Object.mixin and a hypothetical "mixin" superclass combinator that someone might define in the future.
What about multiple sources? That might take almost all the perceived conflict away.
On Thu, Jun 13, 2013 at 5:38 PM, Brendan Eich <brendan at mozilla.com> wrote:
Allen Wirfs-Brock wrote:
I personally don't see that there is any real conflict between Object.mixin and a hypothetical "mixin" superclass combinator that someone might define in the future.
What about multiple sources? That might take almost all the perceived conflict away.
This would also apply to Object.assign
On Thu, Jun 13, 2013 at 2:38 PM, Brendan Eich <brendan at mozilla.com> wrote:
Allen Wirfs-Brock wrote:
I personally don't see that there is any real conflict between Object.mixin and a hypothetical "mixin" superclass combinator that someone might define in the future.
What about multiple sources? That might take almost all the perceived conflict away.
The question which help to solve is: "Why not to have multiple sources?" If there are strong concerns, then one source is the way, otherwise multiple sources seems more functional.
Dmitry
Rick talked about a third argument but if that won't exist I like multiple sources too.
It's also more suitable as Object.mixin(target, ...[source1, source2, source3]) for predefined collections of mixins to reuse
+1 here
If one thinks about how Andrea Giammarchi might have come up with his already reliable implementation of [Object.mixin] ...
[WebReflection/object-mixin/blob/master/src/object-mixin.js]
... the need for changing the order of arguments most probably will become less desirable.
It combines both approaches that today's developers rely on if they try to "extend" or "augment" objects. If it was just for the many implementations of [*.extend] that do stepwise copy properties from one object to another it wasn't even worth discussing it. The second approach mostly gets referred to as "functional or function based mixins" - and Andrea's implementation of [Object.mixin] ...
function ( target, // object to enrich with source, // mixin object or Trait (Function) args // optional arguments for Trait ) { ... }
... considers the different variants of this composition pattern by providing/allowing a third parameter for what I'm willing to call a "Privileged Trait" or a "Privileged Mixin".
var PrivilegedTrait = function (injectedReadOnlyState) { // implementation },
obj = {
// description
}
; PrivilegedTrait.call(obj, {state:"readonly"});
//source.apply(target, args);
Looking at the last line of the given example above there was really no other solution than Andrea came up with in order to support in a future proof way what already exists today in various ways - though neither amount nor precedence of this methods arguments should be changed.
Secondly. What are the advantages of invoking [Object.mixin] with more than one source over the disadvantage of loosing this methods clean interface if there is [Array.forEach] ...
[source_A, source_B, source_C].forEach(function (source) { Object.mixin(target, source); });
Thirdly. Andrea's approach easily can be "shimmed" for ES3 and does not hide JavaScript's natural/native predisposition for Trait/Mixin composition under to much syntactic sugar.
Last. Only if there should ever the naming of "mixin" seriously be questioned again I would propose to choose [Object.compose] as an alternative.
additional links that might proof what I just brought into discussion: [www.mail-archive.com/es-discuss@mozilla.org/msg22677.html] [petsel/javascript-code-reuse-patterns] [petsel/javascript-code-reuse-patterns/blob/master/source/components/composition/Traits/PrivilegedTrait.js] [petsel/javascript-code-reuse-patterns/blob/master/source/components/composition/Mixins/PrivilegedMixin.js]
oh dear ... I forgot I wrote that Trait proof already ... well ... I am willing to change/improve/modify that script if necessary, just let me know what's the final decision (yep, that was an early shim out of emtpy specs :D)
thanks for pointing that out
I propose to change the arguments.
The second argument "target" is optional and default to "Object.create(null)" The return-value is the modified target
Advantages:
misin.(source, target)
Disadvantages