Closed CarmJos closed 11 months ago
In the past two days, I have roughly reviewed this project twice, and I know that it is quite difficult to deconstruct and support this feature.
I wonder if there is a better idea to achieve this requirement?
I looked at this, and it's not easy to do... static
, copy or setters are not good solutions. I need to think about
Is there any possibility that provide a builder method to add external registry for instances? In this way, we can also move the general types into a single, static external registry, instead of registering all of them in final build()
.
Is there any possibility that provide a builder method to add external registry for instances? In this way, we can also move the general types into a single, static external registry, instead of registering all of them in final
build()
.
okey, @CarmJos what do you think about this? #331
Is there any possibility that provide a builder method to add external registry for instances? In this way, we can also move the general types into a single, static external registry, instead of registering all of them in final
build()
.okey, @CarmJos what do you think about this? #331
This pr given a better solution for implementing the applyRegistry(LiteCommandsBuilder<SENDER, SETTINGS, ?> builder)
in the topic.
But maybe we also need a registry like "External Public Registery" for other arguments. Because if we just only supplied all commands the same registries, in the build()
function, primary arguments will be registery again and again, witch may cause problems.
So let's think about the further solution!
But maybe we also need a registry like "External Public Registery" for other arguments.
This is the problem with decentralized object-oriented architecture of litecommands (we assume that litecommands instances are independent of each other), also it is not possible to have two registries (because the parser's search mechanics require viewing the entire register to resolve argument keys, input types, output types and namespaces).
But we can copy all parsers from one to another registry, or you can implement a custom registry (ParserRegistry interface) with additional static fields.
But maybe we also need a registry like "External Public Registery" for other arguments.
This is the problem with decentralized object-oriented architecture of litecommands (we assume that litecommands instances are independent of each other), also it is not possible to have two registries (because the parser's search mechanics require viewing the entire register to resolve argument keys, input types, output types and namespaces).
But we can copy all parsers from one to another registry, or you can implement a custom registry (ParserRegistry interface) with additional static fields.
That's okay. It's enought that the hardest part has been solved.
I'm using this library in a large server project, and I expect to be able to maintain a public "Argument Registry" so that when a plugin registers a new
Argument
, it can be updated to all plugins/commands that use this public Registry, thereby avoiding the need to register anArgument
each time and improve Code unity and atomicity.For example, a main project called "xxCore" provided
User.class
andFoobar.class
.If i want to use those arguments in other plugin like
xxLobby
, i must re-register those arguments and resolvers to support it.And then, a new project called
xxLobbyTime
requires aLobbyUser.class
argument fromxxLobby
...Many arguments are reqiured to be registered if every plugin use the single, finalized, private
ParserRegistery
andSuggestRegistry
.I tried some hacky ways like:
And recode all register functions:
Then register all arguments by myself (replacing those registry means all default arguments will be cleared).
Well, this is too painful and ungraceful.