On backwards-compatible event implementations
asiekierka opened this issue ยท 2 comments
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?
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.