On Jun 19, 2012, at 12:37 PM, Jeremy Ashkenas wrote:
> On Tue, Jun 19, 2012 at 3:33 PM, Allen Wirfs-Brock <[email protected]>
> 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:
>
> http://coffeescript.org/#try:fun%3F.call(undefined%2C%20args)%0A%0Awindow.method%3F.call(window%2C%20args)
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.
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 ?.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss