Existential operator (was: ||= is much needed?)
allen at wirfs-brock.com
Tue Jun 19 13:35:17 PDT 2012
On Jun 19, 2012, at 12:37 PM, Jeremy Ashkenas wrote:
> On Tue, Jun 19, 2012 at 3:33 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> > foo.bar?(args) <==> foo.bar?.call(foo, args)
> > fun?(args) <==> fun?.call(undefined, args)
> How are these equivalent? Won't fun?.call evaluate to undefined if fun is undefined and undefined(undefined,args) will throw...
> ... check out the compilation:
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
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.
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?
Basically, I see what the code you generate is doing but the unlying semantics that yields that code is less obvious.
> It doesn't eagerly evaluate to undefined ... the value of the *entire* expression is undefined if the chain is broken at the existential operator. That's much of the point of soaks:
> object.property?.i.can.keep.chaining.in.here.without.throwing.errors.if.property.is.undefined ;)
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 ?.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss