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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
