I might have an easier time following if there were some small code examples.
For example, the article mentions that for simplicity some components require other components to exist. That sounds like something that cannot be encoded in the type system of most languages, whereas the fields present in classes within a class hierarchy are encoded in the type definition.
A code example would help me figure out if I'm following or not.
In C# and Unity, you have the class attribute "RequireComponent" which will automatically add the dependent "MonoBehaviour" when this one is added:
[RequireComponent(typeof(RigidBody))]
public class MyObject : MonoBehavior { /* ... */ }
This is not really in the type system, but still, if your language provide some meta-programing features, it can help the developer makes sense of your code.
This kind of dependency is not a "type dependency" IMHO, since the data are independent of each other. It's more like a "logic dependency", where the logic of one System requires the logic of another System.
It is the systems you want to apply to an entity that will dictate what components it needs.
Since it can change during runtime, this cannot be statically typed.
I think I know the answer, but I'll ask explicitly.
Suppose we have two components: A and B. A is defined to `RequireComponent` B. If I do `has(object, A) && has(object, B)` then can the C# compiler compile away the check for B given the check for A, turning it into just `has(object, A)`?
IIRC, all "RequireComponent" does is allow you to omit the "add(object, B)" when you "add(object, A)".
A simple example of this is when you add A to the object, then edit A to require B. The Unity Editor won't add B automatically (which is in fact a pain).
NB: removing A will not remove B, and B won't be replaced if it existed before.
I usually use "RequireComponent" whenever I have a "GetComponent<...>()" in my behaviour just to make sure I have an initialized value.
For example, the article mentions that for simplicity some components require other components to exist. That sounds like something that cannot be encoded in the type system of most languages, whereas the fields present in classes within a class hierarchy are encoded in the type definition.
A code example would help me figure out if I'm following or not.