"Optimise" JavaScript code taking advantage of the fact a function can access all local variables in the scope of the caller.
Is there a good explanation of how/why this is bad/unmaintainable practice? To me, it seems more maintainable than making an external function that requires you to pass the caller scope manually... and wouldn't a good engine make those kinds of optimizations?
This is a very old text, and I believe he is not referring to function closures (as I assume that you assume) but crazy shit like the long-since-deprecated-but-still-works arguments.callee.caller.arguments
For example:
function test() { console.log(arguments.callee.caller.arguments); }
function test2(a, b) { test(); }
test2('x', 2);
Will print ['x', 2]. That is horrid; it makes it so you need to know the calling context to determine the behavior (and it could be globally anywhere; in a completely different .js file or even dynamically generated). With a closure the context of a function can generally be determined by simple static code inspection.
this is actually quite a well written and amusing exploration of antipatterns that are used or arise organically, especially in design-by-committee or firefighting shops.
I'd say finding this article hilarious would correlate well with professional coding experience :] and also I honestly had to laugh at myself a few times reading it, clearly laid out these ideas are obvious but they can be sneaky sneaky
Agree. However this article makes me dead angry because of dozens of self-called overcoders who would love to (or do) believe this is how it should be in reality. ... Aaaargghh.
"Optimise" JavaScript code taking advantage of the fact a function can access all local variables in the scope of the caller.
Is there a good explanation of how/why this is bad/unmaintainable practice? To me, it seems more maintainable than making an external function that requires you to pass the caller scope manually... and wouldn't a good engine make those kinds of optimizations?