Why are there different Listener types?

Discussion in 'Plugin Development' started by apiocera, Jul 18, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    I am trying to write an omniscient and omnipotent plugin, and a list of events this plugin needs to process changes in realtime, possibly even when processing some another event. I had to write several different classes overriding Listener for every event type to work around such feature. This has severely complicated architecture of my plugin and almost drove me insane.
    I ran into createExecutor and discovered that a single org.bukkit.event.Event object is dispersed into various event types before being pushed to a certain *Listener converted from org.bukkit.event.Listener taken as a parameter to PluginManager's registerEvent.
    This leaves me to a question: is there any detour to stop bukkit from doing unnecessary work and leave all Event handling to me?
    tl;dr - need Event, not eg. PlayerJoinEvent, coming into my Listener, not eg. PlayerListener.
    P.S. Java has interfaces, why don't you use them?
  2. Offline


    > Implying they're not being used.
    > Bukkit is pretty much a collection of interfaces and enums.
  3. Offline


    Not where I need them. All Listeners are implemented as classes derived from org.bukkit.event.Listener (which is actually an interface, yes) and I can't actually understand why.
  4. @apiocera Interfaces can ONLY have abstract methods that you have to override. Thus, if the *Listener-classes would be interfaces, you would have to override every single onXXX-method for the interface - if you registered your event or not.
    It's kinda unfortunate that you can't use a single class for different event-types. But it would be even more of a hassle to always override tons of methods just to listen to one single event.
  5. Offline


    Or there would be one interface per event.
Thread Status:
Not open for further replies.

Share This Page