SpongePowered/SpongeAPI — pull request #234 by sk89q (2014-11-26 09:35:41+00:00)
Title: Convert all events types to concrete classes

**This branch is primarily for discussion, but the current likelihood that it will be implemented is HIGH (though not necessarily in the form of this branch's commits).**

Right now, events in the API are interfaces. The plan is to convert them all to concrete classes. This comes with some advantages and disadvantages.

## If we keep them as interfaces

The advantage:

* Mapping our events to Forge events is very easy. For example, since our block events are interfaces, we can just have Forge's events implement our interfaces (by rewriting the Forge classes at runtime).

The disadvantage:

* Constructing events becomes quite messy because you need factories (`EventFactory.createBlockChangeEvent(...)`). It gets pretty inconsistent especially when all plugin-provided events would likely be concrete classes (`new MyPluginEvent(...)`).

## What makes this difficult

The main difficulty is that we want to maintain correct event handler ordering between the Forge events and Sponge events.

This is what SHOULD happen:

* Handler for Sponge event handler at FIRST priority
* Handler for Forge event handler at FIRST priority
* Handler for Sponge event handler at LOW priority
* Handler for Forge event handler at LOW priority

This is what should NOT happen:

* Handler for Sponge event handler at FIRST priority
* Handler for Sponge event handler at LOW priority
* Handler for Forge event handler at FIRST priority
* Handler for Forge event handler at LOW priority

(or the inverse)

If someone fires a Forge event, it should trigger the equivalent Sponge event, and vice versa.

## Fixing the problem

Unfortunately, we do not yet have a sane way to fix the problem.

Here is one crazy proposal:

* Change FML's event bus to handle paired events (both sponge's block events and Forge's block events fire interweaved). This will make the event bus code extremely messy.

## Ignoring the problem

On the other hand, we may choose to ignore the problem for the following reasons:

* Forge events are not as well developed and are a lot more inconsistent than ours.
* This is a lot of work to solve a problem that may not really matter in the grand scheme of things.
* Figuring out a solution may delay the first release.
* A solution can still be implemented in the future without breaking API.

## My opinion

I am currently of the opinion that:

* We should use concrete event classes.
* We should ignore Forge events for now.