I've been writing a mod to integrate the Clojure programming language into Minecraft, and would like to add a better event system. This would involve shoving events into core.async channels, which would then distribute them across the mod. As such, I need a way to catch most, if not all, events in order to process them.

 

So does subscribing to a parent class event catch the child events as well? Such that if I subscribe to just the Event class, I'll catch all events? Or on the other hand, is there a way to plug into the event bus, and handle events that way?

Yes, you can subscribe to just

Event

and you will receive all events. Should you? Hell no. Forge's

EventBus

is highly optimized.

Posting an event is no more than one virtual method dispatch and array lookup and then a for-loop through an array (the array of listeners). Every listener is an instance of a special interface (so a virtual dispatch per listener, which is not avoidable) and then a direct invocation of the target method, no reflection, nothing.

I highly suggest you stick to this system, since there are probably hundreds of events (at least) fired every tick on a busy server (every entity fires

LivingUpdateEvent

just for a start).

 

So yeah, please don't.

 

Hm, would there possibly be a way to directly feed it a Method? Clojure can pass functions around like data, so I could probably make a way to register a function with the event handler. It would still directly call it as a method, but 1.) Wouldn't require a class at all (or an instance of one, it would function as a static method) and 2.) It wouldn't require method annotations (very annoying in Clojure). If you could just register an event from anywhere, it would open up a lot of possibilities, such as auto-subscribing to certain events (such as when syncing entities, or registering extended properties, for example). This is the main issue I'm facing that makes me want such a feature.

Hm, forge has a transforming classloader that it uses, right? Would it be possible to add subscribed methods to the event class using that, then re-registering the class, in order to allow for dynamic event registration?

I am not sure what you are saying but it already sounds horrible

 

Yeah, I think it's impossible. Minecraft Forge's event system is retarded. By that I mean it's very... static. But I suppose that perhaps instead of trying to keep everything in a single event class that gets modified over time, maybe I should just add event methods to the classes themselves.

 

On a side note, I actually tried the global Event subscription idea I had. The game actually didn't lag for the most part. HOWEVER, core.async was trying to push too many events to the central channel. In other words, more events were coming in than could be sorted and subsequently dropped, causing a backlog of events that caused noticeable lag and constant complaints from core.async that it had too many events.

 

TL;DR: You were probably right lol.

Actually, why DO we have to provide an object? Why not a class with static methods?

 

For example, I wanna try putting an event subscription in my entity class, but I don't wanna have to have it registered every single time the entity is constructed, when just a static method will do (as the entity object gets provided by the event anyways).

 

In fact, wouldn't calling static methods technically be faster anyways? So then why do we have to provide an instance?

Forge's

EventBus

is highly optimized.

Posting an event is no more than one virtual method dispatch and array lookup and then a for-loop through an array (the array of listeners). Every listener is an instance of a special interface (so a virtual dispatch per listener, which is not avoidable) and then a direct invocation of the target method, no reflection, nothing.

Forge's

EventBus

is highly optimized.

Posting an event is no more than one virtual method dispatch and array lookup and then a for-loop through an array (the array of listeners). Every listener is an instance of a special interface (so a virtual dispatch per listener, which is not avoidable) and then a direct invocation of the target method, no reflection, nothing.

 

I don't understand how this answers my question. Shouldn't the same be possible with or without an instance?

In theory: Yes. In practice: not really, since forge emits a new class for every handler method so the call will most likely be just inlined or at the very least there will be some kind of prediction there (whether it's the JIT or the CPU doing branch prediction). Virtual dispatch is not expensive anymore unless you actually have a megamorphic call site.

 

So yes, one could pass in a Class<> instead, but we are in OOP here, objects rule, not classes.

 

Ah, I understand.

 

Side note: OOP is somewhat irrelevent, as the language I'm writing for is Clojure, which is FP (Functional Programming) instead. It is why wrapping around Minecraft Forge is quite a bit more monumental for Clojure than a language like Scala: I'm not only bridging the gap between languages, I'm also bridging the gap between mindsets.

 

Anyways, I think I'm done with this, thanks again for all of the help.

First off, writing a Clojure adapter is a fun academic experiment but its not worth the effort to make a real mod in. Trying to do anything in the real world with it is inadvisable.

And calling a system retarded because you have no idea what the hell you're doing is NOT a way to make friends.

The EventBus in Forge is HIGHLY optimized in a way that lets us run whatever the hell we want without any performance impact of the rest of the system.

 

At the end of the day, the Event bus is just an array of IEventListeners.

Whatever the implementation of that IEventListener is we dont give a shit.

If you want to do your static method crap you could easily just write a IEventListener that calls a static method.

 

This shouldnt have to be explained as its obvious if you take 10 seconds to look at the system.

 

But ya, have fun with your Clojure toy, i'd advise you drop it, or put in a modicum of effort before calling shit retarded.

 

On top of that you're developing or 1.8.9, we're on 1.10, get with the times.

 

That being said, you do bring up ONE good point, There is no technical reason we don't allow static methods as event handlers.

It's mainly a legacy from when we originally moved from Guava's EventBus {Which doesnt support it} to our own.

I've got a proof of concept edit already, only like 4 lines of code changed. I'll push it up if cpw cares enough about it.