[Unity ECS] Make an abstract class with generics that affect the inject struct declaration
From the previous topic, a group must be read only if I want to organize my code around struct + interface and I could not have any writable data inside my inject group.
But not all hope are lost, we still can make an abstract class instead of interfaces with nice features… begin with the current design.
How to generalize this JobComponentSystem so that it can be reused later?
I made 2 abstract classes that takes a generic to affect what we get in the injected struct inside. Then I could make a new system without declaring the struct again! A barrier is already declared and injected even, because I always have to rely on it to remove my reactive component at the end.
Notice that I am still using my interface from earlier. The first version is intended to be send into a job with [ReadOnly] as you learned an entire group cannot be written to. Then I can do “fun things” with my extension method for the whole group which only works with a thing marked with IReactiveInjectGroup .
The second “Data” version is intended to be disassembled and send each things to the job one by one. Only get on a data is fine, once we “get” that out from the struct we can write to it in the job. But IReactiveDataInjectGroup would not have much use since we are not sending in the whole group, but it’s there because it might be useful before entering a job to have that interface.
An example when I am using it :
Now I specify my requirement with only <ReactiveComponent, DataComponent> at the class’s head and I automatically get the thing I want without saying a word “struct”!
protected injectedGroup was there to be used whether as a whole or disassembled into a job, also protected barrier is ready to be .CreateCommandBuffer() ‘ed. I can add more [Inject] here as I want too.
You still cannot stramline the struct job creation and must type it + throw data into it manually (since the inside contains the likely not-reusable Execute, and Execute could not be inherited from anywhere) but this is nice enough as it can get. Ok! (With C#8 default interface implementation I think we actually could do more to the job itself on your abstract class.)
