Fabric API

Fabric API

106M Downloads

On backwards-compatible event implementations

asiekierka opened this issue ยท 2 comments

commented

The current HandlerRegistry<...> route has the downside of requiring to create a new field (say, ATTACK_BLOCK_V2, ATTACK_BLOCK_V3...) every time we want to change an interface in a backwards-compatible manner - and such a reason already popped up in 19w03a.

Instead, I'm proposing something with a bit more boilerplate - to have singleton classes for every event (say, AttackBlockEvent), with functional interfaces as inner (V1, V2, ...), and a .register(V1 eventHandler) method, as well as possibly, in the future, .emit(args...) methods that possibly also handle things like cancelling/proxying return values/etc.

Am I being reasonable?

commented

I think it's the best way to do this within the limitations. It'd be rough to break everything every couple updates with no backwards compat.

commented

Solved in 0.2.0.