[MIRROR] Remove data systems in favor of global datums #2242
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Original PR: tgstation/tgstation#82943
About The Pull Request
Removes data systems in favor of global datums. After merge I want to add a contribution guideline in favor of global datums rather than subsystems with no behavior since that seems to be something we don't want.
CC jlsnow301
Why?
The original motivation of data systems is to replace subsystems that don't fire or tick. I don't necessarily know that I agree that that's an issue, but there's enough push in that direction and I don't disagree with it strongly enough to care about it.
However, I am very much against treating these as some special bespoke concept worthy of its own abstraction. I do not see it as providing any value and only adds to confuse.
We can start by acknowledging the types of persistent global controllers/datums we have today:
The behavior of 1 has proven worthy of its own abstraction, as doing so allows us greater control through the master controller. 2, 3, and 4, have NOT, and data systems do not replace them entirely. As an easy callout, data systems are not meant to do any interesting initialize behavior, so the 4th use case is immediately out, meaning things like the highlander controller have to remain in global datums.
But this cost does have a burden on the developer, as there are now 3 unique namespaces (an ACTUAL downside to "namespace pollution") that a mechanic they want to use might be in. What makes "materials" something that obviously isn't a subsystem, and is a data system? What makes highlander something that obviously isn't a subsystem or data system, but instead a global datum?
It also carries a similar problem to components vs. elements, which is that your implementation details are leaked to consumers, and changing those implementation details can carry a heavy cost on your PR. Data systems are not meant to have interesting initialization, but eventually if something like radio does, then now we either have to break that rule for DSradio (which this PR does), or we have to change it to another contraption and change every reference of DSradio to whatever it is now. I would like to reduce that where necessary.
So the new rule that I will propose in contribution guidelines later is simple, assuming we agree that NO_FIRE|NO_INIT subsystems are a smell--subsystems if they do something repeatedly and unconditionally, probably global datums otherwise.