On Jun 19, 2012, at 10:50 AM, Brendan Eich wrote:
> Another problem with your alternative: either it breaks a refactoring
> equivalence.
>
> Let <==> be equivalence for a program fragment, and <!=> be inequivalence.
> Then we have in JS today extended with do expressions (and gensym via $tmp):
>
> foo.bar() <==> do {let $tmp = foo.bar; $tmp.call(foo)}
>
> Now use ?. used instead of dot. Either the equivalence breaks:
>
> foo?.bar() <!=> do {let $tmp = foo?.bar; $tmp.call(foo)}
Why is it important that this equivalence holds for . and ?. We already have
other places using references where similar refactoring aren't equivalent:
typeof foo <!=> do(let $tmp = foo /*Reference error if foo unresolvable)
*/; typeof $tmp)
In particular, I'm pretty sure that this refactoring hazard is not going to be
as significant as the
foo?.bar() //oops I'm really think foo?.bar?()
hazard
>
> Or else your alternative leaks Reference type values into the language,
> observably, because if
>
> foo?.bar() <==> do {let $tmp = foo?.bar; ($tmp == null) ? void 0 :
> $tmp.call(foo)}
>
> then
>
> var fun = foo?.bar;
> fun();
>
> should not throw if fun is null or undefined, but there's nothing in the
> fun() expression to signal this to the implementation or readers. This fun
> would have as its value a new kind of MaybeReference type. We do not want
> this sub-alternative.
No, of course not. You can't allow References to leak to the user value level!
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
