How important is IIFE in RMMV?

● ARCHIVED · READ-ONLY
Started by TheoAllen 52 posts Page 2 of 3 View original ↗
  1. TheoAllen
    #21 Source
    @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.
  2. Trihan
    #22 Source
    Yeah, I'd always intended to update it but never found the time. I'll see if I can do so tonight, Theo.
  3. Aesica
    #23 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.
    Unless I'm not understanding you correctly, of course you can. Consider this:

    Code:
    (function($$)
{
   // You can still alias and/or overwrite this
   // just like you would any other function
   // because it's referencing an object outside
   // the IIFE scope
   Game_Actor.prototype.skills = function(){};

   // You can also alias and/oroverwrite this
   // as Aesica.SomeCrapPlugin.doStuff
   $$.doStuff = function(){};

   // But you can't touch this one, and why
   // would you want to anyway?
   function parseMyPluginParameters(){};

   // this one is also untouchable from the outside
   let parseMyNoteTags = function(){};
})(Aesica.SomeCrapPlugin);

    See, Javascript is the type of language where it's really easy to do things horribly. Looking back at some of my earlier code, especially when I first started learning it, I fell into a lot of those traps and it made things harder to go back and fix later on. "Oh no, all my variables are global! Can I change this function without breaking these other two?"
  4. Trihan
    #24 Source
    I think he's referring mainly to cases where your plugin creates new classes that don't already exist in the global scope; using an IFFE for that means other plugins can't access your classes unless you provide an interface via which to do so.
  5. TheoAllen
    #25 Source
    Aesica said:
    Unless I'm not understanding you correctly, of course you can.
    Obviously you're not understanding me correctly. My context was in Trihan's tutorial (except if it's already rewritten).

    Aesica said:
    Consider this:
    And many of the existing plugins don't consider this. I was not saying it is impossible. Just as far as I can tell, not many do this.
  6. Aesica
    #26 Source
    Aah, well that's just another example of what I said previously about Javascript having lots of ways to do things horribly. If the new class is something that would potentially be useful to other developers, there's no rule saying it has to be in the IIFE with everything else.
  7. Tsukihime
    #27 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.

    I wouldn't want to write my plugin that relies on the existence, or non-existence, of some private "_Scene_Map_createAllWindows" though.
  8. TheoAllen
    #28 Source
    Tsukihime said:
    I wouldn't want to write my plugin that relies on the existence, or non-existence, of "_Scene_Map_createAllWindows" though.
    It won't be a plugin, it will be a patch.
  9. Trihan
    #29 Source
    Aesica said:
    Aah, well that's just another example of what I said previously about Javascript having lots of ways to do things horribly. If the new class is something that would potentially be useful to other developers, there's no rule saying it has to be in the IIFE with everything else.

    It's not so much about what the rules are as what developers currently do.

    I'll give you a prime example of this: One of my most recent commissions is for a menu system plugin that basically rearranges all the windows and adds some window animation/functionality. As part of this, my client wants non-active cursors in windows to blink, but he's also using Galv's image cursor plugin.

    That plugin is inside an IFFE, so I wasn't able to edit the update function directly. Thankfully Galv did add a cursor object property to windows that I was able to hook into, but it was still way harder than it otherwise would have been to implement my client's request. :p
  10. Tsukihime
    #30 Source
    I guess we could all remember to attach the aliased methods to our namespace object

    Code:
    (function($) {
  var $.oldFunc = func
  Something.prototype.func = function() {
    $.oldFunc.call(this);
    // new stuff
  }
})(MyPlugin)
    So that you could then access it via MyPlugin.oldFunc if you wanted to.
  11. Aesica
    #31 Source
    TheoAllen said:
    It won't be a plugin, it will be a patch.
    Again, it's not a matter of IIFE vs everything in the global namespace. It's a matter of some plugin devs not thinking of every angle. I tend to write my override functions like this:

    Code:
    $$.Game_Actor_skills = Game_Actor.prototype.skills;
Game_Actor.prototype.skills = function()
{
   $$.Game_Actor_skills.call(this);
   // other stuff here
};
    For that very reason.

    Edit: That way, you can just reference Aesica.SomeCrapPlugin.Game_Actor_skills if you really want to.
  12. Trihan
    #32 Source
    I think that should definitely be the standard for plugin devs going forward. I'll add a bit about that to my tutorial.
  13. TheoAllen
    #33 Source
    @Aesica tell you what, if many started to do like you do, I wouldn't even begin to create this thread in the first place. Because the problem seems like many just di IIFE because of IIFE. So I began to question why is it so important.

    I think I've already got your point. You don't need to repeat it. The problem is, do you understand where I came from?
  14. Ossra
    #34 Source
    @Tsukihime @Aesica That is what I do. All new and old functions and such are shoved into the namespace for the plugin. For MZ, I am creating a shared function that will allow people to grab the namespace and version of a plugin if it is loaded into the project. So if someone really, really needed to do so ... everything is there.
  15. Aesica
    #35 Source
    TheoAllen said:
    @Aesica tell you what, if many started to do like you do, I wouldn't even begin to create this thread in the first place. Because the problem seems like many just di IIFE because of IIFE. So I began to question why is it so important.

    I think I've already got your point. You don't need to repeat it. The problem is, do you understand where I came from?
    Oh I absolutely get it, but because of that, it might be better for the focus to be on bad and good practices with IIFE vs whether IIFE is good or bad in and of itself. I mean look how long it took for me to figure out what you were actually getting at. :)
  16. Trihan
    #36 Source
    Do you think it might be an idea to look into the possibility of forming some kind of semi-official "plugin council" of well-known or prolific developers to come up with a plugin standard and/or template for devs to use that will avoid common pitfalls and implement IFFE in the positive ways (avoidance of namespace pollution) without the potential negatives?
  17. Aesica
    #37 Source
    Trihan said:
    Do you think it might be an idea to look into the possibility of forming some kind of semi-official "plugin council" of well-known or prolific developers to come up with a plugin standard and/or template for devs to use that will avoid common pitfalls and implement IFFE in the positive ways (avoidance of namespace pollution) without the potential negatives?
    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.
  18. TheoAllen
    #38 Source
    I wouldn't want a council that judges on how I would write my code.
    However, I don't like a misleading guide or tutorial. If someone wants to stray from the guide, it is their choice and also their fault. Not the guide's fault for making them do something wrong.
  19. Aesica
    #39 Source
    TheoAllen said:
    I wouldn't want a council that judges on how I would write my code.
    However, I don't like a misleading guide or tutorial. If someone wants to stray from the guide, it is their choice and also their fault. Not the guide's fault for making them do something wrong.
    I think it's less about judging people's code and more about trying to establish a standard that will make plugin creation easier for everyone.
  20. TheoAllen
    #40 Source
    Aesica said:
    I think it's less about judging people's code and more about trying to establish a standard that will make plugin creation easier for everyone.
    The term "council" seems like a group of people that judges your code. But what you're basically saying is a guideline which is fine by me.