PaperMC
PostOrder and priority
Requested Feature
Deprecating PostOrder seems weird, especially when its better than priority, more human readable, feels like priority should be the one deprecated and postorder non deprecated
Why is this needed?
NORMAL, HIGH etc is more human readable than just "pick a random number" which will make people pick 9999 or -9999, also paper uses human readable event priorities
Alternative Solutions
IDK
Additional Information
No response
The fact that paper uses human readable priorities has been a long standing issue as it limits plugins to the five (usable) defined priorities, making interop between plugins near random and most people without interop plans just leave it as NORMAL, leaving exactly two priorities for plugins to modify their output.
A short does not have such a limitation while still allowing the exact same "usage". If you need a specific priority around e.g. monitor, there is MAX_VALUE. Otherwise, it just enables a lot more interoperability between plugins without having to rely on API interfaces and dependencies. The initial deprecation was not done without this in mind, I don't think this issue is something I'd like to see implemented, even though I do not work enough on velocity to have a say in this decision.
The fact that paper uses human readable priorities has been a long standing issue as it limits plugins to the five (usable) defined priorities, making interop between plugins near random and most people without interop plans just leave it as NORMAL, leaving exactly two priorities for plugins to modify their output.
A short does not have such a limitation while still allowing the exact same "usage". If you need a specific priority around e.g. monitor, there is MAX_VALUE. Otherwise, it just enables a lot more interoperability between plugins without having to rely on API interfaces and dependencies. The initial deprecation was not done without this in mind, I don't think this issue is something I'd like to see implemented, even though I do not work enough on velocity to have a say in this decision.
I get that finer grain control over the priority is nice, but deprecating the simple version seems like an odd choice, if it MUST be removed, it'd be nice if Postorder enum had a short added to it for priority so we can do something like
@Subscribe(priority = PostOrder.EARLY.getPriority())
Yes, that might be a semi usuable addition. Just, yea, as seen in your example, becomes a bit impossible when it really could have just been PostOrder.EARLY if that were to be a short. Might be something fun to add for the one day release of velo 4 (move PostOrder to a short). I guess a helper type like this might work, EventPriority or smth could be added to not use a deprecated type (and to not call a method in an annotation lol)
Just a note regarding Paper, Velocity, and plugin inter-compatibility. That plugins are highly encouraged to use hardcoded priorities, like @Listener(priority = EventPriority.NORMAL), is the major reason for conflicts between them. As a result, event handlers aren't configurable, plugin developers usually rely on intuitition about the priority they "should" choose, users are caught in the middle, and values can't be changed due to backwards behavioral compatibility concerns.
Using an enum is just one ingredient in the matter, but switching to integer values is not the end of the story. Using integer values therefore won't deliver a significant improvement, unless plugins actually make their event handlers configurable in priority, where relevant.
The Velocity API thankfully allows using programmatic priorities, but it might need more documentation and/or awareness-raising in order for plugin developers to adapt them. Myself, for example, I have yet to do so...
