2 ms·
We gave up on TCP for => function syntax. I think Java reached the same conclusion. It's really hard to retrofit TCP onto a C-like language with statements as
by BrendanEich 14y ago
We gave up on TCP for => function syntax. I think Java reached the same conclusion.
It's really hard to retrofit TCP onto a C-like language with statements as well as expressions. At best you please only some programmers and confuse others, at a fairly high implementation cost (e.g., return from within a lambda called after its containing function deactivated).
See https://mail.mozilla.org/pipermail/es-discuss/2012-March/021872.html https://mail.mozilla.org/pipermail/es-discuss/2012-March/021... and especially https://mail.mozilla.org/pipermail/es-discuss/2012-March/021879.html https://mail.mozilla.org/pipermail/es-discuss/2012-March/021....
- surrealize 14y agoThanks, it's nice to hear it from the horse's mouth. Does it make sense to think about TCP as being a matter of degree? Would it be correct to say that the number of constructs that would break TCP is fewer with let, const, and => than with earlier versions of ES? I think a "partial TCP" would matter for manual refactoring, if not for (e.g.) a future macro system. On the other hand, perhaps it's more confusing to mention it if it's not total.
- BrendanEich 14y agoSaw dherman's comment just now, he and you are right that there is a spectrum of TCP, and if you use a subset of JS to write expression-bodied => functions, you get the refactoring property that people associate with TCP.
- dherman 14y agoThough the expression version of => comes pretty close to TCP. Dave