On Jul 18, 2011, at 1:39 PM, Sean Eagan wrote:

> On Mon, Jul 18, 2011 at 1:44 PM, Allen Wirfs-Brock
> <al...@wirfs-brock.com> wrote:
>>> Also, how about |> as opposed to <&, since it is a dual to <| adding
>>> own rather than inherited properties?
>> I'd be a bit concerned about  some people getting confused about which 
>> direction of the "arrow" corresponds to each operation.
> I think the arrow-to-operator correspondence would be fairly easy to
> remember... "extension arrows point back in space to prototypes which
> exist back in time , and forward in space to own properties which will
> exist forward in time".

Whatever happens, we mix metaphors:

1. <| is pointing in the reference direction of __proto__ aka [[Prototype]].

2. <& is pointing to the copy destination.

However, making the arrow point to the right mixes yet another metaphor:

3. +> or whatever points to the copy sources.

I do not think 3 helps as much as it hurts.

Separate point: left to right assignment or copy operation is confusing in many 
languages, and right to left is the norm. This goes back to assembly variants 
(gdb x86 vs. Intel ASM). JS uses right to left assignment direction. I think 
this must matter.

>> I like the nemonic value of having + or & as part of the operator symbol for 
>> "extend" but  unfortunately <+ can't be used.
> One thing to note is that <& would disallow using & as a unary
> operator in the future.

Yup. No plans there.

> Here's another option to consider:
> // replace <| with <>
> let B = A <> {...}; // looks like a (prototype) chain link

How so? That link is unidirectional. I don't buy it, and <> historically means 
not equal or unordered.

> // then +> could make sense
> let b = B +> {}; // "adding" pointed to properties.

See above.

es-discuss mailing list

Reply via email to