On Tue, Jun 19, 2012 at 4:35 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote:
> > Ah, interesting...so this is actually close to what I was advocating for > this particular case. However, if I now understand correctly you are > saying that > fun?.call() > produces undefined if fun is null/undefined but will throw if fun is > defined as: > fun = new Object; > because it doesn't have have "call" property. > Yes, exactly. > Also, it isn't clear to me why the second example > (window.method?.call(window, args)) is only guarding for null and not > undefined. Is it only because you guard for undefined on variable > references and not on property references? > Ha ha, loose equality strikes again! It's actually guarding for both null and undefined. It's the only place that CoffeeScript purposefully uses the in-all-other-cases-avoided != operator. undefined == null, right? Ah, again. I don't think Brendan's strawman will produce that result. The > ...?.i is going to get undefined when it does GetValue on the Reference > produced for object.property. Then undefined.can will throw in step 5 of > 11.2.1 because the LHS is undefined. Getting this behavior seems to > requires modifying . as well as defining ?. > I'm afraid I can't speak to the spec language or strawman ... but the basic idea with soaking is to short-circuit evaluation as soon as the soak fails. In the same way that: window || a.b.c ... won't error even if a is entirely undeclared ... window.a?.b.c ... won't error even if a is entirely undeclared.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
