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

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 18 15:50:19 PDT 2011


On Jul 18, 2011, at 1:37 PM, Brendan Eich wrote:

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

You're right it can be viewed that way.  Even though I know that = or += and friends are just operators I think I tend to think of them more like a statement form.  Also all the other assignment operators are operations upon values and they modify a variable rather than mutate an object.  I see where you're coming from on this but personally that lack of symmetry with the other assignment operators feels more disconcerting then the lack of symmetry with <|.


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

Yes, if the symmetry argument would be my primary reason for restricting the RHS.  But then <& could be use for things like:

Object.prototype.extend = function (obj) {this <& obj};


Allen 


More information about the es-discuss mailing list