How important is IIFE in RMMV?

TheoAllen · 2019-03-13T19:36:57+0900

About IIFE: https://developer.mozilla.org/en-US/docs/Glossary/IIFE This morning, I had an interesting discussion from one of the discord chat (with @Aloe Guvner to give them some credit). Some brought up that it is not something to promote in MV plugin making. While I sort of understand, I didn't really voice my opinion on because I barely made anything in MV to understand that. However, that doesn't mean it isn't bothering my mind. Generally, what I've seen is it is to avoid naming conflict. It encapsulated in a private block of function so your variable isn't accessible outside of it. But the question are > How common is the name conflict? > Can you just use your own name pattern like _ _ ? I don't believe if it will be too common to get conflict. Additionally, you can just use your own namespace (like how Yanfly did it)? > Do you consider a plugin that doesn't do an IIFE is a kind of... heretic? > So why even IIFE? Any other benefit that I don't know? Or other drawbacks (aside from the conflicting name)? > Do you promote to some of the (potential) new plugin dev to use IIFE?

● ARCHIVED · READ-ONLY

Started by TheoAllen Mar 13, 2019, 10:36 AM 52 posts Page 3 of 3 View original ↗

Trihan

#41 Aug 3, 2020, 10:11 AM Source

Yeah, I didn't mean it in a regulatory kind of way, more like what the W3 Consortium does for web design. "This is the recommended way to do this stuff, but ultimately it's up to you."
Solar_Flare

#42 Aug 3, 2020, 05:25 PM Source
TheoAllen said:
@Trihan maybe you would be better to start updating the thread and add "How to expose your variable to global window" because your example in your thread suit best for my example as of "you can not patch someone's plugin without directly edit the file" :p

Because with IIFE is on the way, I could not make an overwrite patch that does an edit like from this

Code:
Scene_Map.prototype.createAllWindows = function() { _Scene_Map_createAllWindows.call(this); this.createMinimapWindow(); };
to this (a separate file plugin that must be placed directly below the plugin)

Code:
Scene_Map.prototype.createAllWindows = function() { _Scene_Map_createAllWindows.call(this); do_something_in_between() this.createMinimapWindow(); };
Because _Scene_Map_createAllWindows is private in IIFE.
There was never been a problem like this in RGSS.

Because many people would refer to your tutorial when it comes to plugin making. And not sure if they would bother to read the comments.
You literally just did exactly what you said you can't do - you wrote an overwrite function that does something before creating the minimap window. Sure, it might be ugly to copy-paste the whole function and add your extra line, but if it's just a patch to fix a bug or something, who cares?

An actual plugin (add-on or whatever) however shouldn't be relying on some other plugin's aliased methods.
Tsukihime

#43 Aug 3, 2020, 06:17 PM Source

Aesica said:
I dunno, actually. Would people adhere to its guidelines, or even knew it existed for that matter? It'd depend largely on how much of a reach it was able to have.

Ya it's mostly about reach.

If you create 100 plugins and literally everyone uses them, and compatibility was terrible with other people's plugins, you still own the market share and everyone else needs to figure out how to work with your stuff lol

The first thing people ask is "is this compatible with Yanfly Engine" and I'm always like "I don't know, there are dozens of plugins which one are you talking about"
Hudell

#44 Aug 3, 2020, 06:22 PM Source

Since rpg maker doesn't use import syntax, I think it's important to use IIFE to avoid filling the global context with your stuff. Anything that should be "modifiable" by other plugins should then be exported from the IIFE.
Eliaquim

#45 Aug 3, 2020, 09:12 PM Source

I personally don't like the use of IIFE. I like to type(or let the autofill feature type for me) Namespace.pluginNameSpace.functionName(or variable). It feels more readable for me and it looks nice to my eye xD.

Also, with a namespace for the author, and another namespace for the plugin, it almost impossible to have a clash in the global scope( in the context of plugins for Rpg Maker MV).

There are other things that are more important to make a plugin compatible with others than using IIFE or not. In my last commissions, I have to make a thing compatible with two plugins from different authors. One of them use IIFE and it was an easy thing to do. The others don't, and it was hard because of the way the plugin has coded.

So I guess it's up to the coder on what it will take for use to make his own plugins.

Yeah, I didn't mean it in a regulatory kind of way, more like what the W3 Consortium does for web design. "This is the recommended way to do this stuff, but ultimately it's up to you."
I think that is a nice idea. As long as it does not take sides to choose, like:
"This coder follows the guide, this coder is nice and welcome"
"That coder don't follow the guide, so let's say that this kind of coder is not nice for the community"

Because, although, we coders will understand that it is not a big deal(I mean it will make no difference if this plugin is good or not), the users who don't know how to code can take it differently and somehow avoid using the plugins from this author.

So it's a good idea, but I also don't see that the community must have it.
Tsukihime

#46 Aug 3, 2020, 09:23 PM Source
Eliaquim said:
I personally don't like the use of IIFE. I like to type(or let the autofill feature type for me) Namespace.pluginNameSpace.functionName(or variable). It feels more readable for me and it looks nice to my eye xD.

Also, with a namespace for the author, and another namespace for the plugin, it almost impossible to have a clash in the global scope( in the context of plugins for Rpg Maker MV).

The clash that usually is problematic is when two methods decide they need to overwrite the same method.

One plugin wants to return 1, another plugin wants to return 2.
I don't think there's really a way to get around this, especially if it's a common object.

For example think of battle systems: some want to have have turn-based, some wants to have real-time.
You might be able to get away with
Code:
if (mode == "turn based") // turn-based update else if (mode == "real-time") { // real-time update }
But sometimes this isn't possible. It needs to be designed from the ground-up to improve flexibility.
Eliaquim

#47 Aug 3, 2020, 09:37 PM Source
Tsukihime said:
The clash that usually is problematic is when two methods decide they need to overwrite the same method.

One plugin wants to return 1, another plugin wants to return 2.
I don't think there's really a way to get around this, especially if it's a common object.

For example think of battle systems: some want to have have turn-based, some wants to have real-time.
You might be able to get away with

Code:
if (mode == "turn based") // turn-based update else if (mode == "real-time") { // real-time update }

But sometimes this isn't possible. It needs to be designed from the ground-up to improve flexibility.
Oh yes, that's right. Totally agree with your last phrase. I think that is what I mean this, but I do not make myself very clearly:

There are other things that are more important to make a plugin compatible with others than using IIFE or not. In my last commissions, I have to make a thing compatible with two plugins from different authors. One of them use IIFE and it was an easy thing to do. The others don't, and it was hard because of the way the plugin has coded.
I think in this case there is no workaround besides looking at the two plugins and make a change in the code or a totally new plugin taking it into consideration.
TheoAllen

#48 Aug 3, 2020, 10:41 PM Source

Solar_Flare said:
You literally just did exactly what you said you can't do
Which is why I said it is suited best for my example.

Solar_Flare said:
Sure, it might be ugly to copy-paste the whole function and add your extra line, but if it's just a patch to fix a bug or something, who cares?
I've been doing this practice over the years to help people in RGSS and it worked really well. They don't need to know anything, just apply the patch below the script to either change the script behavior, fixing the bug or provide compatibility patches. It is technically not editing people's code which, in theory, shouldn't matter and I don't need permission.

I even do that in my project to preserve the original code in case I need to look back on what is the original code looks like. There are a lot of overwriting. I wanted to do the same thing in JS plugins.
TheoAllen

#49 Aug 15, 2020, 08:14 AM Source

公式プラグインを読み解く | プラグインを作ってみる | プラグイン講座 | RPGツクールMZ
Apparently the practice of this IIFE (one that does not expose it to the global scope) is endorsed officially.
DoubleX

#50 Aug 15, 2020, 08:36 AM Source

I can't read Japanese yet, and I don't know if I'd be too unreasonable to ask someone to make a summary here on why and how exactly the officials endorse the IIFE that intentionally seals off some important variable/function accesses :)
TheoAllen

#51 Aug 15, 2020, 08:42 AM Source

Here is the machine translation because apparently, my chrome auto-translate any page that is not English/Indonesia.
DoubleX

#52 Aug 15, 2020, 09:27 AM Source

Assuming that the translation's correct, to me, these reasons aren't strong enough to seal off access of some variables/functions that can be useful for some other plugins(compatibility issues, plugin A using plugin B, etc), as the same issues can also be solved by passing a plugin container(that can be accessed globally) designated to the plugin inside the IIFE and stores everything that would be otherwise private into that plugin container, and it not only won't seal off access of any variable/function, but also assign them to a proper namespace, so they can be identified as being under the designated plugin :)