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 

> 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.

es-discuss mailing list

Reply via email to