On Oct 4, 2011, at 6:17 AM, Russell Leggett wrote:
> That's why I was trying to make it less error prone and verbose.
Understood, but we should not "scenario solve" with ad-hoc, compound additions.
We seek orthogonal primitives that compose well, and the harder scenarios
ideally desugar.
>> If you are assuming .{ binds to the result of evaluating the unparenthesized
>> <| expression to its left, then there's a precedence problem.
>
> I was assuming <| was evaluated first because that's how I read
> Allen's pattern working as well. I'm wondering how Allen's even works
> now.
The <| operator must not take an arbitrary expression on its right, because
that allows for mutation of [[Prototype]] on an escaped "old-born" object.
But <| could take literal forms and "concatenations" of literal forms via
.prototype.{...}.constructor, e.g.
Or <| binds tighter than . (but I think this would be a mistake).
> My thought was that if func <| obj => func, then .{ would go on
> the resulting function.
No, func <| {...} makes an object whose [[Prototype]] is func.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
