What's wrong with anonymous functions?

[Shaz]

Triggered by this comment but I didn't want to get into the discussion in that thread.

one thing that bug me...

some plugins that wrap in anonymous function

(function() { // …})();it's okay... but the problem lies when they alias something but using private variable inside that anonymous function. this mean the old method cannot be accessed by other plugins.

(function() {  var estMyOldFunction = Game_Enemy.prototype.opponentUnits;})();

we cannot access the estMyOldFunction thus the Game_Enemy.prototype.opponentUnits before modified is LOST...at least store the old function inside a module / container wrapper !!!

I don't understand this. The kadokawa plugins all use this:

(function() { // ...)}();and I've written all of my plugins to follow the same format.I think what you're saying is you can't access the original, unmodified version. But if you have a number of plugins that all modify the same function, wouldn't you want the mods to stack? What situation would there be where you have two plugins that modify the same function, where you want one plugin to ignore the mods of the other?

 

[nio kasgami]

I will explain by yanfly message who explained me why anonymous function are "bad" for MV

Sent 26 October 2015 - 01:42 AM
Anonymous functions are harmful for MV because of the community-setting we have. Because we have more than one scripter, there comes the need for eventual compatibility patches.

For that reason, debugging each other's plugins and whatnot becomes a bit tougher. It's not impossible, but it can be a pain. Anonymous functions cannot be reused unless you use the right scope, cannot be tested in isolation with a unit testing framework, etc. Just because a practice is widely used doesn't mean it's necessarily the right way to approach it (remember when people used to use HTML tables for website layouts?).

 

[Hudell]

Yes, they meant that if they wanted to make a compatibility plugin between two other plugins, they may need to call the older method of one of them. When you alias a method to a simple var inside the anonymous function, that var can't be accessed from anywhere else.

But there's nothing wrong with anonymous functions, in fact, it's bad NOT to use them. The problem estriole mentioned lies with using something inside it and not exporting it to be accessed outside.

I don't bother exporting my aliased methods because I can make compatibility patches myself.

 

[DarknessFalls]

because everything inside that anonymous function is scopped to that function, including aliases. This is great if you are creating classes, functions, varaibles and so on that cannot be mutated randomly by people trampeling all over the code base.

I use this concept in the form of modules. In ES6 for example when you export something or import something, when compiled down it wraps the code in these types of functions.

 

[Shaz]

Shouldn't plugins be like black boxes?


Is this ONLY an issue when you're trying to make a compatibility patch between two?


Can anyone give an example of two plugins - actual code (hypothetical is fine) where this would become a problem, and an example of how they could be written to overcome the problem?


I'm just trying to determine whether I should go back and redo all of mine.

 

[Zalerinian]

Shouldn't plugins be like black boxes?

Is this ONLY an issue when you're trying to make a compatibility patch between two?

Can anyone give an example of two plugins - actual code (hypothetical is fine) where this would become a problem, and an example of how they could be written to overcome the problem?

I'm just trying to determine whether I should go back and redo all of mine.

Honestly, you should be fine. As far as I can think, the only issues really come up when it comes to compatibility patches. However, the way I make my scripts, all aliases are stored in my own "module" (It's a JS object ( { } )) that I store all plugin parameters and aliases in. This way, the functions I aliased can still be accessed as they were before I changed them. This way, should someone need to make a compatibility patch with one of my plugins, it's easily doable for them, in the event that I'm not able to do it myself. The anonymous function, in my case, isn't really required for most plugins since I don't really create that many variables outside of a function, but I do it to both encourage the use of it, and to follow the standards that are used in MV.

 

[nio kasgami]

two plugin who alias the same update

// original methodSpriteset_Base.prototype.initialize = function() { Sprite.prototype.initialize.call(this); this.setFrame(0, 0, Graphics.width, Graphics.height); this._tone = [0, 0, 0, 0]; this.opaque = true; this.createLowerLayer(); this.createToneChanger(); this.createUpperLayer(); this.update();};// method A called beforevar alias_A = Spriteset_Base.prototype.initialize;Spriteset_Base.prototype.initialize = function() {alias_A.call(this);//your content};// method B called aftervar alias_B = Spriteset_Base.prototype.intialize;Spriteset_Base.prototype.initialize = function() {//your contentalias_B.call(this);};you may encounter bug with the update method.

SINCE if you do method A they will call update BEFORE material is created. 

SO if example I do method A...it's just create something new and don't update without a flag. then it's fine

BUT method B require to always update. then it's will be fine to call it.

Now here begin the problem if we input the plugin.

If method A is call before Method B it's will provoke a crash of no method since ...update is call BEFORE method b is call. so this why Anonymous don't help here since we can't reach the other method alias for do this :

var alias_A = alias_B.prototypeSpriteset_Base.prototype.initialize = function() {alias_A.call(this);//your content};where it's will get the content of B and not provoking bug. Although not the best performance method

EDIT : 

the problem with alias in general are they are hierarchical and  depends of the specific order you call them. The way's to fix this would be the way's you organize your plugin order so method_B would not get a error since it's alias is call before method A so it's have time to get call.

 

[DarknessFalls]

Shouldn't plugins be like black boxes?

Is this ONLY an issue when you're trying to make a compatibility patch between two?

Can anyone give an example of two plugins - actual code (hypothetical is fine) where this would become a problem, and an example of how they could be written to overcome the problem?

I'm just trying to determine whether I should go back and redo all of mine.

This becomes a problem when, for example:

Currencies, it has a shop functionality.

Detailed Shops Script - re-writes shop functionality, look and feel.

These two are incompatible because my "black box" depends on functions and functionality either not present in this or other functions.

For me, I like the concept of modules or anonymous functions because at the end of the day I don't want you walking all over my code. Other people would say this is bad because if I change functionality then there script is screwed. What you do is something like:

(function() { var oldGameInterpreterPrototypeCommand125Method = Game_Interpreter.prototype.command125; Game_Interpreter.prototype.command125 = function() { // Your code ... oldGameInterpreterPrototypeCommand125Method.call(this) }}();By making sure you always always always call the old function you make sure that other peoples scripts still work with your stuff. its when you decide not to call the old method that we have an issue.

 

[Milena]

Honestly, you should be fine. As far as I can think, the only issues really come up when it comes to compatibility patches. However, the way I make my scripts, all aliases are stored in my own "module" (It's a JS object ( { } )) that I store all plugin parameters and aliases in. This way, the functions I aliased can still be accessed as they were before I changed them. This way, should someone need to make a compatibility patch with one of my plugins, it's easily doable for them, in the event that I'm not able to do it myself. The anonymous function, in my case, isn't really required for most plugins since I don't really create that many variables outside of a function, but I do it to both encourage the use of it, and to follow the standards that are used in MV.

I don't understand. You mean, if you create your own module and you place all the aliased values in it, should it all still be callable in a new plugin written in a different format? Forgive me but I want to understand this as well. Say for example, I write something like this:

(function(){ var Milena = Milena || {}; Milena.params = PluginManager.parameters('DiarySystem'); Milena.DiaryStstem = { someAliasStyle: { Game_Screen: { update: Game_Screen.prototype.update, } } };})();Does this mean that when someone, right before, a plugin, accesses Game_Screen's update, be able to include all the updates you've done with Game_Screen when they alias it too?

 

[Iavra]

You should declare "Milena" outside the function, otherwise it won't be accessible by other plugins or the user.

 

[Milena]

Ha... thanks, now I understand. <3

 

[estriole]

Shouldn't plugins be like black boxes?

Is this ONLY an issue when you're trying to make a compatibility patch between two?

Can anyone give an example of two plugins - actual code (hypothetical is fine) where this would become a problem, and an example of how they could be written to overcome the problem?

I'm just trying to determine whether I should go back and redo all of mine.

from what i experienced... the only issue is when we're trying to make compatibility patch. no other issue other than that.

in my opinion... used or not... when we alias we shouldn't remove reference to old method. it's just like overwritting things instead of alias...

 

[DarknessFalls]

when we alias we shouldn't remove reference to old method.

this. a thousand times this.

 

[Hudell]

from what i experienced... the only issue is when we're trying to make compatibility patch. no other issue other than that.

in my opinion... used or not... when we alias we shouldn't remove reference to old method. it's just like overwritting things instead of alias...

Have you ever had a situation where the reference was of any use?

 

[estriole]

Have you ever had a situation where the reference was of any use?

yes in fact i have... when writing compatibility patch between my autocolor plugin and yanfly message core.

second one is when writting compatibility patch for Galenmereth Mouse System Ex.

it would be lots harder to make the patch if the old method reference is lost.

 

[DarknessFalls]

Have you ever had a situation where the reference was of any use?

the reference helps keep backwards compatibility.

 

[Kino]

Just so I can understand this a bit better.

For example, with aliasing and creating our black box plugins.

So for example as Zalerinian mentioned.

They store the old aliases  in a js object.

Example:

//Maintain global scopevar module = { //list of aliases to be used. }(function(){ //references to functions from the module //my code here })();We should be doing something like the above?

Also, would it be a good idea to reference our anonymous function as it's own module if we wanted other users to have access to it?

Example:

var myPlugin = (function(){//plugin code})();Or is this a bad idea?

 

[Tsukihime]

Shouldn't plugins be like black boxes?

Is this ONLY an issue when you're trying to make a compatibility patch between two?

Can anyone give an example of two plugins - actual code (hypothetical is fine) where this would become a problem, and an example of how they could be written to overcome the problem?

I'm just trying to determine whether I should go back and redo all of mine.

I wouldn't say plugins should be black boxes.

They should be black boxes to people that will be using them and don't need to worry about how it works, but for developers that may need to modify your plugin one way or another, they would need a way to do so.

For example, I don't define anonymous methods.

var TH = TH || {};(function ($) { $.myFunc = function () { // something }})(TH.Namespace);If anyone needed to touch that method later on, they can use

TH.Namespace.myFunc

to access it.Now if someone didn't have a way to access myFunc, and they actually wanted to add something to it...well, they'd probably be stuck.

 

[Iavra]

Also, would it be a good idea to reference our anonymous function as it's own module if we wanted other users to have access to it?

Example:

var myPlugin = (function(){//plugin code})();Or is this a bad idea?

This won't reference the function, but its return value.

 

[DarknessFalls]

Just so I can understand this a bit better.

For example, with aliasing and creating our black box plugins.

So for example as Zalerinian mentioned.

They store the old aliases  in a js object.

Example:

//Maintain global scopevar module = { //list of aliases to be used. }(function(){ //references to functions from the module //my code here })();We should be doing something like the above?

Also, would it be a good idea to reference our anonymous function as it's own module if we wanted other users to have access to it?

Example:

var myPlugin = (function(){//plugin code})();Or is this a bad idea?

var myPlugin = function(){//plugin code}; // if your plugin is one function then this is a plugin.