-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor function
functions to something better behaved
#9362
Comments
Currently, the occurrence of matches of |
function
functions to something better behavedfunction
functions to something better behaved
WebStorm has a standard |
One way forward would be to fix the problems we found in https://github.com/JamieMason/eslint-plugin-prefer-arrow-functions The 4608 attempt used version 3.1.4 and it's on 3.3.2 now, but I don't see the problems addressed in https://github.com/JamieMason/eslint-plugin-prefer-arrow-functions/blob/main/CHANGELOG.md |
A long time ago now we did a contentious analysis of which of JS's many ways of writing functions we should include in our normal programming style. The controversial answer, which I still hold to, is to almost always avoid
function
functions. The problem is that they have too much extraneous semantics beyond their normally intended use.function
functions have a construct behavior and a distinct call behavior.function
functions have aprototype
property whose value is initially a novel empty object.function
function declarations hoist in initialization time, unlike every other scoping construct.function
function declarations are exported early in an import cycle, before the module has initialized, making it syntactically burdensome to ensure they are hardened before an importer can access them. This was the fatal problem.All these harm ocap security in the small. Again, especially the last "fatal" problem listed above.
We still need to remove almost all uses of
function
. The only justified uses I know of arenew
(construct) behavior. For this purpose, anew.target === undefined || Fail…
can emulate the absence of a call behaviorfunction
with a construct behavior.#4608 tried applying an automatic refactoring tool to transform
function
functions to arrow functions. However, it was naively textual and had too many errors (for me) to trust it. IIRC @Chris-Hibbert says there’s a good such refactoring built into intellij, but it was unclear how to apply it to a large corpus.Not all
function
functions should be transformed to arrow functions. A tiny number should remainfunction
functions for one of the above two reasons. Of the remainder, those that mentionthis
should probably become concise methods.We already almost never use
var
andclass
, so removingfunction
functions would leave us onlylet
andconst
, both of which are extremely safe, predictable, and well behaved.The text was updated successfully, but these errors were encountered: