On Jul 18, 2011, at 12:16 PM, Allen Wirfs-Brock wrote: > On Jul 18, 2011, at 11:32 AM, Brendan Eich wrote: > >> Hawt. >> >> A bit rough in that LHS <& RHS mutates LHS, whereas LHS <| RHS is pure and >> produces a new object (which could be optimized to mutate RHS, note well!). >> Both <| and <& are operators, to support chaining. Would it be better for <& >> to be pure as <| is, and make an assignment operator form, LHS <&= RHS, that >> expands to LHS = LHS <& RHS? > > One way to think about <& is as a more declarative and more concise > alternative to Object.defineProperties. I think there are plenty of use > causes for the mutating extends. For example, adding properties to the > prototype object of a function. Another issue is that the object you need to > extend may already have been captured somewhere. For example, a > super.constructor call might have registered the object in a WeakMap and if > <& created a new instance you would loose the identify relationship.
Sure, I'm not saying word one against the mutating form -- just noting the symmetry break w.r.t. <| and suggesting a fix that builds on the assignment operator. > In practice, I think most of the more declarative uses such as adding own > properties can be implemented (and perhaps even specified) such that no extra > objects need to be created. Agreed. > One thing that I think is still open is whether the RHS needs to be an > ObjectLiteral or whether any object producing expression should be allowed. > All the use cases I have explored use an ObjectLiteral but I don't see any > hazard (like would be the case if <| mutated the LHS [[Prototype]]) with > allowing a non-literal value of the RHS. Probably right; another symmetry break. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
