An Argument Against Requiring IIFEs - Revision history

Yanfly at 11:23, 8 November 2021

2021-11-08T11:23:59Z

2021-11-08T11:23:03Z

‎Introduction

2021-11-07T23:47:07Z

‎Introduction

2021-11-07T23:43:40Z

‎Programmers Admitting They're Lazy

2021-11-07T23:33:28Z

‎Introduction

2021-11-07T23:25:26Z

‎Isolation of variables, making them private and unchangeable

2021-11-07T23:24:08Z

‎Not Polluting the Global Name Space

2021-11-07T23:21:22Z

‎Isolation of variables, making them private and unchangeable

2021-11-07T23:20:52Z

2021-11-07T23:08:57Z

‎Introduction

@@ Line 138: / Line 138: @@
 As you can see, isolating and privatization of variables makes usage of IIFE's for that purpose moot.
 === Running an unnamed one-time planned function ===
@@ Line 276: / Line 278: @@
 Just keep in mind that if your whole reason to require usage of IIFE's is to allow you to be lazy, you're not going to be doing a very good job of convincing people on why IIFE's are required to wrap a plugin.
 == Conclusion ==
@@ Line 293: / Line 297: @@
 If they have reasons to use IIFE's that aren't listed here, all the more kudos to them.
 However, if you are being fed those reasons, make sure you can distinguish if they're applicable to you as a responsible programmer.
 == End of File ==
 |}

@@ Line 23: / Line 23: @@
 This has applications, yes, and from personal experience, there are times where its useful, too.
-However, there's been a trend in the RPG Maker community, especially amongst plugin developers, that argue that entire plugins are '''required'' and need to be wrapped around in an IIFE.
+However, there's been a trend in the RPG Maker community, especially amongst plugin developers, that argue that entire plugins are ''required'' and need to be wrapped around in an IIFE.
 I personally don't believe that they are '''required''' a single bit.

@@ Line 27: / Line 27: @@
 I personally don't believe that they are '''required''' a single bit.
-Here is why.
+And as a person who used to get a lot of $#!% back in the day for not using them, here is why.
 == The Common Arguments In Favor of IIFE's ==

@@ Line 275: / Line 275: @@
 (and in case you're wondering, this article is just made as a counterargument towards the required usage of IIFE's, not pushing my own programming practices on anyone else)
-Just keep in mind that if your whole reason to using IIFE's is to allow you to be lazy, you're not going to be doing a very good job of convincing people on why IIFE's are required to wrap a plugin.
+Just keep in mind that if your whole reason to require usage of IIFE's is to allow you to be lazy, you're not going to be doing a very good job of convincing people on why IIFE's are required to wrap a plugin.
 == Conclusion ==

@@ Line 24: / Line 24: @@
 However, there's been a trend in the RPG Maker community, especially amongst plugin developers, that argue that entire plugins are '''required'' and need to be wrapped around in an IIFE.
 I personally don't believe that they are '''required''' a single bit.
 Here is why.

@@ Line 97: / Line 97: @@
 On top of that, modules are also automatically isolated within their own functions.
 'let' and 'const' allowed the restrictions to go to even smaller scopes, such as their own bracketed conditional blocks.
 <pre>

@@ Line 41: / Line 41: @@
 <pre>
-// This is what "polluting the namespace" looks like, while using
+// This is what "polluting the namespace" looks like:
 var x = Window_Base.prototype.initialize;
 var y = Window_Base.prototype.lineHeight;

@@ Line 99: / Line 99: @@
 <pre>
-const createId = (function () {
+const createId = (() => {
-  let id = 0;
+    let id = 0;
-  return function () {
+    return () => {
-    id++;
+        id++;
-    return id;
+        return id;
+   }
 })();
@@ Line 134: / Line 134: @@
 As you can see, isolating and privatization of variables makes usage of IIFE's for that purpose moot.
 === Running an unnamed one-time planned function ===