Component System TODOs

This page is a fairly hodge-podge list of things that we either should do, or would be worth considering or experimenting with, in no particular order so I can just add to the list as things occur to me (or anyone else). Some of them are super vague and abstract, others are really specific TODO tasks. This is basically the wiki equivalent to the scrap of paper I usually keep around me so that other people can read it. Feel free to add to the list!

• Use the different appropriate platform/build defines when running the systems-scanner tool. This is actually harder than it sounds, because the systems scanner always uses clang and Windows include paths to parse the C++ files, so if we're doing osx specific stuff inside PLATFORM_OSX defines the scanner won't know what to make of it. Debug and release alternatives might be doable though.
• Add some sort of constant/immutable modifier to components, which means the component can only ever be added to Inputs and not Outputs. This allows for certain types of data which are set up at the start and used, but never modified over the lifetime of the entity.
• Create a sort of "entity unit test" whereby you can use a special syntax in the yml definition of an entity to declare "I think this entity ought to be running at least these systems". Then we can statically check at build time whether the entity has all components required to run those systems. Beware, though, because sometimes you are reliant on other parts of the hierarchy (parents), which aren't specified in the entity yml.
• Right now, when we add or remove components to an entity, we flag it as "dirty". Then, we run GetInputOutputs() for all systems on that entity. An alternative would be to add the entity to a dirty list for the actual systems which require that component. That way, we only need to run GetInputOutputs() on the systems that are actually affected, not all systems.
• Related to the "constant component" thing mentioned above, here are the four types of components that Alex and I envisioned when we were talking about it a while back. Normal components that we use for most things are number 4; the constant components I mentioned earlier are number 2:
  1. Init only data - Specified in the .yml and used during initialisation, but never used after that (so it can be thrown away and we might be able to get away without creating a component pool for it at all) -- EDIT: Initialize events tend to make this redundant
  2. Constant data - Specified in the .yml, set up during initialisation, and then accessible in the Inputs of systems, but never the Outputs, thus not writable.
  3. Runtime only data - NOT specified in the .yml, instead set up during initialisation, and then accessible in systems.
  4. Normal components - Specified in .yml, with read/write access via the normal system mechanism.
• While writing the above list it occurred to me that whether the data is specified in .yml or not is somewhat orthogonal to whether it is mutable at runtime, so perhaps treating it as a list of four types is the wrong approach, and it should be more of a matrix between "mutable/constant", "implicit/explicit" (i.e., specified in .yml or not), with the init only data being a bit of a special case. Just a thought!