Brendan Eich wrote:
Clarity depends on many things including how well documented or
commented the code -- especially that contract that we just agreed
exists -- might be.
One thing I forgot to write:
With array extras such as forEach, almost always the contract is local
and needs no docs or comments. Indeed people write
function outerMethod() {
...
anArray.forEach(function (elem) {
... this /* oops */ ...
});
...
}
IIRC this was an error from real life that tomvc showed to the list.
Implicit, local contracts where lexical |this| is required are exactly
the use-case for =>. Kevin Smith's analysis, although it studied only a
few codebases and isn't some kind of definitive empirical study,
suggests that this use-case, combined with those where functions don't
use |this| at all, dominate.
But now I'm repeating myself. The point here was that the contract is
often local and even implicit in the sense that JS hackers, even
experienced ones, fall into the trap.
As with most programming errors, there's no perfect defense in style or
language restriction short of avoiding |this| altogether. But there's
good clarity based on the local contract and implicitly lexical |this|
in the above code rewritten to use =>:
function outerMethod() {
...
anArray.forEach(elem => {
... this /* yay! */ ...
});
...
}
I'm sorry this doesn't extend to your mixin library. If we had -> then
your users who want shorter syntax would have a choice, but that choice
creates the option to choose wrongly, and the extra complexity combined
with the common-case analyses from Kevin and others caused us to add
only => to ES6 as proposed.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
