An "extend" operator is a natural companion to <|

Brendan Eich brendan at
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:
>> 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.


> 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 mailing list