Multiple Event Methods for the same Event

  • If I have one method marked as @EventMethod and listening for the PlayerCommandEvent and a second separate method again marked @EventMethod and listening for the same PlayerCommandEvent in the same plugin, executing a command in game will trigger both of them right?


    So to the real question now, will this kind of coding slow my plugin down? i.e. instead of one EventMethod for each event having multiple smaller ones to separate things out i.e. 1 for each different command type, 1 for each different Gui Tab, etc.?

  • I surely cannot answer your question; I am not even sure I understand them. In fact, I do not understand why you should break an event handler down into several equivalent handlers.


    I mean: each handler would still have to check the event to see if it has to handle it or not. So, ultimately instead of



    you will end up with something like:



    Is there any gain?

  • Well ok maybe the command event was a bit of a bad example but if I have 50 clickable GuiElements and want to handle all of them with if else loops in the same event handler it quickly gets to 100s of lines of code and it is just not clean enough to read for me :D


    Thus my main question was not if there is gain but if there is any loss by splitting it up. If there is loss then I will put everything in a single long handler else I will split it up into many of them in different classes to keep it cleaner :)

  • Well, for sure there will be some loss: we can assume that listeners are held in some container which is then enumerated (and each listener called) when the relevant event is detected.


    So, for a 50-GuiElement "dialogue box" (I am using the term in a generic sense) and for click events:
    *) there will be 50 insertions in the container instead of 1 at dialogue box creation;
    *) 50 deletions from the container instead of 1 at dialogue box destruction;
    *) 50 function calls instead of 1 at each relevant event;
    *) some code will be repeated in each listener handler;
    *) 49 of those function calls will return without doing anything but after having tested that the GuiElement returned by event.getGuiElement() is not this (functionally equivalent to a 50-case switch in a one-for-all listener, but possibly slower).



    Of course, a lot of details would depend on what precisely you aim at, but if the 50 GuiElements are there at the same time, they are presumably not 100% independent one for each other and some additional code will be required to let the GuiElements (or their parents) to communicate to each other the outcome of the events; more code to write, debug and execute (which also does not help code readability and maintainability).


    I am not an expert of Java performance, but I would expect the CPU additional load to range from trivial/unnoticeable to sizeable depending on how many listeners there are, how frequently this happens and specific implementation details of RW code and of your code.


    However, the whole concept does not strike me as an improvement; I understand that handling, say, click events for 50 elements may lead to a very large method; I personally would address this by splitting the method with local method calls when necessary.


    So, for instance:


Participate now!

Don’t have an account yet? Create a new account now and be part of our community!