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)}
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.
/be
Brendan Eich wrote:
Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I still stand by my alternative semantics as being a way to address
the more important use case without have ?()
No, the basis cases differ and that is a bug in your alternative.
foo?.bar means take bar from foo or undefined if foo == null.
foo?.bar() means take bar from foo and throw if foo == null else try
to invoke the result if typeof "function", else undefined.
This is an off-by-one bug.
It also uses ?. to mean . and magically applies the ? to the later ().
Or if the semantics suppresses a TypeError both for the "take bar" and
"invoke it" parts, then it's mixing two things in one under syntax
located in the wrong place for the second suppression. Mainly,
suppression should be precise and at the point of application -- where
the dot goes if getting or setting, where the left paren goes if
invoking.
Also, if you agree that the ?( case in CS is less significant, then we
shouldn't add it in haste or mangle ?. semantics to try to cover it.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
