What's wrong with anonymous functions?

[estriole]

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.

this could work as well. Galenmereth use this approach in his mouse system ex.

just for me though... as long as the original function before modified is not lost... using anonymous / not is not a problem .

is there any benefit on using anonymous function beside not polluting namespace ?

since for polluting... we can add the alias inside:

var EST = EST || {};EST.pluginName = EST.pluginName || {};EST.pluginName.oldGameEnemyOpponentUnit = .........
and we contain our alias in one 'EST' module / container

unless there's other benefit beside that. i might also change to using anonymous if it's really have difference.

 

[Tsukihime]

If you need access to the original function before I alias it, you should instruct to have yours placed above it.

 

[Galenmereth]

I will be using the structure I use in MouseSystemEx for all my plugins going forward. That is this one, mentioned earlier:

var TH = TH || {};(function ($) { $.myFunc = function () { // something }})(TH.Namespace);

is there any benefit on using anonymous function beside not polluting namespace ?

since for polluting... we can add the alias inside:

The benefit is that you can use local objects not intended to be used by anyone else in the anonymous function enclosure, and it's also much easier to keep track of scope when using a shorthand scope var like $ for all namespaced objects and methods, like in the example.

 

[Kino]

var TH = TH || {};(function ($) { //Added a new plugin to the namespace $.plugin = { newFunc: function(){ //stuff } }; //Doesn't show up in our object testFunction = function(){ //stuff } $.myFunc = function () { // something };})(TH);console.log(TH);//Added a new plugin to the namespaceTH.Plugin2 = {};console.log(TH);This is rather interesting, cause this function  and the namespace declaration are very clear.

But what I do like is the fact that, any function not declared with the alias ($) for our namespace doesn't show up in the function isn't added to the object.

And we can still extend the namespace with an object literal.

 

[DarknessFalls]

I prefer to blackbox my code, I think its safer that way

 

[Galenmereth]

@DarknessFalls: Only if you plan to release your plugin in complete isolation from everyone else's. There are many instances where black boxing is ok, but it's not always the case.

 

[DarknessFalls]

If you need access to the original function before I alias it, you should instruct to have yours placed above it.

You shouldn't have to. You should be able to call the original parent code and then it should call your code. Yours would be the last peace of code to execute. If I remember my research correctly.

@DarknessFalls: Only if you plan to release your plugin in complete isolation from everyone else's. There are many instances where black boxing is ok, but it's not always the case.

This is what I do. I always release in isolation, if you look at any of my scripts they are wrapped in self executing functions.  When I alias other functions I always make sure to call the parent function to keep backwards compatibility. I treat MV like a framework or a platform that I build on top of and I try not to do destructive things that would break other peoples scripts.

I also try an abstract my logic as much as possible so that I don't have to alias as much as I would normally have too. The only issue I have had so far is detailed shops script where they re-write everything or blow away specific instances of the shop, which I outlines in a couple articles is a horrific thing to do. (even provided ways to do what you want but not be destructive)

 

[Galenmereth]

Same here, and now that I know the workings of MV better I intend to improve my plugins on that front too, making them more encapsulated. Yet it's still beneficial to make some functions readily available in a namespace for other developers, for them to add onto or make compatibilities on their end. MV isn't really a framework because its individual parts are too tightly bound together, often in very non-modular ways. In these instances it's important not to make your plugin completely encapsulated.

 

[Tsukihime]

You shouldn't have to. You should be able to call the original parent code and then it should call your code. Yours would be the last peace of code to execute. If I remember my research correctly.

Assuming this is what's going on in my code

Old_StuffMy_stuffAnd someone wanted to change Old_Stuff, they would need to be able to access the aliased method which contains the old stuff. Since my aliases are anonymous, they wouldn't have access to them.If for some reason they want to make it so that

if CONDITION  do old stuffelse  do my stuff

Then they're pretty much out of luck since they have no way to access the old stuff.

 

[Iavra]

In general, i try to keep everything encapsulated inside my own plugin. The only stuff i make public are:


- classes, especially for visual stuff (sprites, windows, scenes), so it's easy to modify the visual aspects of my plugins.


- API calls (obviously). Most of these are also callable via plugin commands.


- Some select functions/objects. For example, in my achievement plugin, there are 3 built-in types of achievements (manually triggered, by switch and by variable). Those classes are registered in a "mapping" object and i made it public, so it's easy to extend the plugin with additional achievements, if needed.

 

[Galv]

In the event that someone needs to get the original function before it was aliased, couldn't they copy+paste the original function code to make a new function to use for their own purpose?

 

[Galenmereth]

That would rarely be a good solution, and in most cases a very problematic thing to do. What if the original function is later changed for some reason? Suddenly the old broken version lives on in potentially many plugins out there. Recipe for disaster in almost all cases. Yet I've had to do it once now for a compatibility fix, but I wish I didn't.

 

[Iavra]

You'll need 2 plugins in this case:


- 1 that runs before the plugin you want to make a compatibility fix for and stores the old version of the function in a public variable.


- 1 that runs afterwards and uses the stored function.

 

[Galenmereth]

In my case the issue was with the isDatabaseLoaded() function; I need to call it before the Scene_Boot starts, which was too early for some data reading extensions made to it in other popular plugins. Now I could require my plugin to be placed before all other plugins, aliased isDatabaseLoaded() and stored it, and called the alias when I needed to check the status. In this singular instance I went with duplicating the function because it's a very tiny and self-contained function which in the off-chance that the original is changed, I would need to update other areas of my plugin regardless because it would mean a core change in the core boot and load structure. So I went with the more user-friendly route. But I might change this later on, though, and go for another solution entirely for my PreloadManager.

 

[DarknessFalls]

In general, i try to keep everything encapsulated inside my own plugin. The only stuff i make public are:

- classes, especially for visual stuff (sprites, windows, scenes), so it's easy to modify the visual aspects of my plugins.

- API calls (obviously). Most of these are also callable via plugin commands.

- Some select functions/objects. For example, in my achievement plugin, there are 3 built-in types of achievements (manually triggered, by switch and by variable). Those classes are registered in a "mapping" object and i made it public, so it's easy to extend the plugin with additional achievements, if needed.

THIS ^

 

[ArkDG]

I've adopted the pratice to expose all my parameters variables, so I can use its values in addons for my plugins. Some should say I'm making something stupid (they are right), because if another person uses the same variable names inside any function, this might break my plugin entirely (or other reasons I dont even know). But I do signature my varibles with the plugin file name or a special code that if some other one uses too would be on purpose of trying to break everything. (so this person would be a $@%#$#)

 

Then, why to don't expose either the aliasing variables and a variable with my changes inside a function too? 

 

 

===================

 

var mypluginfilename_var1 = aliasedFunctionTobeOverwrited();
var mypluginfilename_var2 = undefined;

(function () {  

function myChanges() {
   //my content };

aliasedFunctionTobeOverwrited(){
  mypluginfilename_var1; //the old method
  myChanges(); // My function with what I want to happen here
  mypluginfilename_var2 = myChanges(); 
//now this variable has my function inside it and everything after this can use its value, but the other variables I call inside it are still protected.
};
})();

====================

 

This way people would be able to reorganize the functions as they want in their plugins or adaptation, as long as they remember to call all the variables. Don't they?

 

[DarknessFalls]

I 

var mypluginfilename_var1 = aliasedFunctionTobeOverwrited();var mypluginfilename_var2 = undefined;

IMO this looks bad. You should just do var x = y inside your function

 

[Kino]

I think the style I'll stick with is the parameter passing anonymous function.

But include an object for old aliases outside my function, or include a space for aliased functions in the my personal namespace.

 

[DarknessFalls]

I think the style I'll stick with is the parameter passing anonymous function.

But include an object for old aliases outside my function, or include a space for aliased functions in the my personal namespace.

This is a more ES5 proper way of doing it.

 

[ArkDG]

I 

IMO this looks bad. You should just do var x = y inside your function

 Well, I have to declare these variables in public domain so my method takes effect. If I do this inside my function, there is no point doing this.

But if you mean the second part being called inside the function...

mypluginfilename_var2 = myChanges();

Well, provided the variable declaration to be outside the anonimous function, I should change the variable value from anywhere I want.