An "extend" operator is a natural companion to <|
brendan at mozilla.com
Mon Jul 18 13:37:10 PDT 2011
On Jul 18, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
> On Jul 18, 2011, at 11:32 AM, Brendan Eich wrote:
>> 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.
> 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.
More information about the es-discuss