Ok so I have another update message for 4.0 I guess.
I was running into an issue where I could not have changing information about the placeholder (such as configurable descriptions) due to the fact that it was in an annotation. So I ended up redoing much of the system again, and came to a better, two part but single faced solution.
From now on, all placeholders will be registered with an ExpansionBuilder
. This builder allows you to fluently build and register placeholders, and supports BOTH the @Placeholder
annotation system AND a functional parsing method system. This way, you can create methods with the @Placeholder
annotation that can have dynamic information, or you can create a parse method implementation (with support for numerous functional arguments, such as BiConsumer<Source, Token>
(proper types will be displayed when you use it in the builder)). I haven’t yet made a way to directly add @Placeholder
annotated classes to the registry rather than using the builder, and I am unsure if I am going to, but that will be in the changelog if it is.
The default placeholders will no longer appear in the config file to enable or disable; instead, I will be adding a command to enable or disable them on the fly. While not exactly beneficial on RAM (and I have some tests I am going to do to figure out if and how I can lower the profile of the plugin further), it saves time from going into the config file and changing it, then having to reload the plugin.
I should mention that, in my last post, I said that I am not using reflection because it saves on performance: to clarify, I decided to do automatic class generation instead because I expect plugins to, in the future, be making rapid and numerous calls within short periods of time, for instance for scoreboard plugins updating every tick. The fact that this saves on roughly 4 times the performance (despite being unnoticable in normal use cases) will help many servers who use such plugins, I think.
The annotations I added last time will still work, except now the void
return type IS supported, and will just return an empty value when replaced in text.
I ditched some of the LoadingCache
s because they were more confusing to use than maps and, while they worked well, they don’t exactly fit the use case. I might return to them or something similar in the future to save memory, but the issue is that, if I try to use a weak referencing system or something else to save memory, I will run into missing placeholders and that is worse than a bit more RAM usage. I still have to test the RAM usage so this may not even be an issue, but I think it’s worth at least talking about as it may change how developers use the plugin.
As with last time, the source code is all on GitHub so any suggestions (particularly relating to this issue) would be lovely.