SpongeAPI | SpongeCommon | SpongeForge
This is a new API and implementation of a high-level command system to bring the design inline with Sponge's general design and to try to resolve some of the perceived weakness of the system. It was one of the things I said I'd look into when I joined the Sponge team... so here we go!
Motivation & Goals
The command system is out of place in the current ecosystem and parts of it can be difficult to use. It doesn't have much in the way of abstraction, and this is hindering potential development of it. I've also seen quite a few plugins eschew the argument system, preferring to just split the string and doing the parsing themselves. Consider the following points:
- It was built early in Sponge's development (API 2, I believe), and hasn't really seen much daylight since (unlike Texts, which is effectively on version three).
- The argument (parameter) building is just a load of wrapped elements, and can be difficult to follow (one example of this is Nucleus' TP command)
- Many many objects can be created for each command, most of them duplicates of one another - we can try to reuse some simpler objects and potentially reduce Sponge's footprint a little bit.
- It's all API implemented, and cannot take advantage of optimisations through Sponge implementation, nor is it easy to make some changes without causing a major breakage (though this may be by design, see the consideration below)
- There are few interfaces, mostly final classes, and this makes it hard to make a slow transition to newer structures, effectively making it more difficult to make positive changes in a none breaking manner.
So, as a result, I've been playing about with creating a new high level system to try to make it easier to resolve, if not resolve, some of the issues that currently plague the system.
It's not finished, and it certainly doesn't work right now, but with community help, we can flesh out a system that is hopefully more flexible and more usable than before.
It's also possible that this ends up being a very bad idea and/or more complex than before and thus doesn't get merged. A major goal is to make the command system, particularly parameters/arguments a little easier to work with, if we can't do that, this PR will become worthless.
Another goal is to modularise the system enough so that we can build other systems around it with ease, for example, some annotation based system could make use of the value parameters independently, and modifiers can be specified independently, without worrying about how the wrapping might otherwise work. However, that's further down the road.
Consideration: do we want some of this to be put into Common?
- The purist point of view is that the Sponge API should not contain significant implementation detail. Little implementation should be in the API, except for things that would be of great use of plugin developers (see the PatternMatchingValueParameter, as an example).
- Having implementation in Common allows us to use the full power of the Sponge system, having wider use of the backend to be able to shortcut some things we might otherwise have had to do in the API.
Third party implementations, on the other hand, may benefit from API implementation - this would make the command system consistent amongst different platforms, and as it doesn't need to rely on Minecraft, it doesn't matter where it goes. However, this means another library to consider.A halfway house would be to make the implementation part of the command system an external library shaded in, and only otherwise depends on the API - third party implementations can then depend on our solution, whilst keeping the API clean for developers to work against.
This is something that needs some careful consideration, but right now, I'm going to keep things split API/Common, because I still think that having the API interfaces and the implementation separate as much as possible is a plus, and this way, it forces me to think about how to keep things separate. It shouldn't be too difficult to move things around if necessary.
Answer: yes. This is being split into API and Common. There will be a couple of minor useful classes for developers to use in the API, but the bulk of the implementation will be moved into Common.
Heads up! This will break almost every plugin out there.
It has been decided that we’re just going to break things. Plugins that use commands will break when this is pulled, no way around that. However, as discussion has shown: it’s the preferred chioce and it makes things much easier on us.
This is where the developer community comes in!
This PR is in very early stages, as such, I'm looking for feedback and suggestions on the direction of travel of the API. Things will change, ideas will come and go. It doesn't quite need a review yet, but feedback on the ideas are more than welcome. I will try to write up specifications of what I'm doing as I go in the comments, ready for (constructive) feedback and ideas.
system: command branch: bleeding status: wip api: 8
![[WIP] Add EconomyService API](https://avatars.githubusercontent.com/u/702071?v=4)
![[Suggestion] List of all generated chunks](https://avatars.githubusercontent.com/u/4605410?v=4)
1 Jan 13, 2022
6 Aug 30, 2022
56 Dec 28, 2022
110 May 25, 2022
10 Jan 28, 2022
13 Feb 10, 2022
4 Jan 30, 2022
3 Nov 15, 2021
4 Dec 24, 2021
4 Sep 7, 2022
3 Nov 12, 2022
6 Oct 17, 2022
38 Dec 16, 2022
10 Dec 10, 2022
2 Jul 9, 2022
14 Dec 25, 2022
3 Dec 23, 2022
6 Dec 7, 2022