Would adding support for contravariant (or covariant, I always forget) queries be possible?

[Meigs2]

I'm looking at using arch for one of my future projects, though this is not a deal-breaker feature I need, I think it might be interesting if the library had support for contravariant (or covariant) queries.

For example, let's say I define the following:

public interface ITest {} // define a common interface
public struct A : ITest {}
public struct B : ITest {}

Using arch, something like the following would not work:

world.Create(new A());
world.Create(new B());

var query = new QueryDescription().WithAny<ITest>();

world.Query(in query, (in Entity e) => {}); // never ran! There's no archetype for ITest, just for A and B.

Here's a .Net Fiddle for this example:
https://dotnetfiddle.net/eoSTxA

I had a skim of the source code and I assume for performance reasons the type passed in is used when querying. However, I feel like there has to be some usages where you'd want to create a common interface and have each object determine it's behavior when ran.

Is this already a feature? If not, I'd suggest either:

1. DI-style "registration" of contravaraint types, which the world would keep track of and automatically create new archetypes when creating/removing/updating entities and their components.
   • Example:
     • world.Register<A, ITest>(); // updates all A's to be in archtype of ITest, query would then work or:
     • world.RegisterInterface<ITest>() // scans all types that implement ITest and updates them
   • Downsides:
     • There is no compile-time verification that A is a ITest, checks would have to be made at runtime.
     • Newly added entities would need to be tracked too, adding overhead when creating entityes
2. If this is already supported under-the-hood, extend QueryDescription's API to allow for getting all of a type
   • Example:
     • new QueryDescription().OfType<ITest>(); // same API as Rx.NET, OfType<T>() would return all events of type T or more specific in that framework.
   • Downsides:
     • Added complexity to API

Thoughts? Though I haven't used Arch in a project yet, I can see this being very useful in a few projects I have plans for.

I'd also like to say that this could also definitely be "OOP" thinking, as I'm relatively new to ECS's and there may be a better suited approach to solve this problem.

Thanks!

[genaray]

Thanks for checking out Arch! :)

That's really a good question. I would first say that this would be possible, but in a way it clashes strongly with the principle of ECS and Arch.

One could simply keep a dictionary in the background with this information and check with every operation if there is a subtype and deliver it. But such mechanisms are slow and not really common... you would also quickly run into problems like what happens at : entity.Add<A,B>(); var whatDoIReceive = entity.Get<ITest>(); and many other little difficulties.

Also, this paradigm violates ECS fundamentals and data-oriented programming ^^ There should be no inheritance and systems should always know what to do with components. Sure components may contain interfaces, but getting type A or B from an interface violates this paradigm because it is not acting on the data, but on an interface.

Normally this is simulated in different ways. You could e.g. give the components an enum to indicate that they inherit from something or write your own .Get/.Has method to encapsulate this functionality.

public static boolean HasByInheritance<T>(this in entity entity){
    var archetype = entity.GetArchetype(); // Get Archetype entity is located in
    var componentTypes = archetype.Types; // The components in this archetype
    // Loop through ComponentType[] to check whether its ComponentType.Type is child of interface and therefore return true or false
}

So you could simulate this quite easily ^^ According to this you could also add your own little query API...

public void MyQuery<T>(in QueryDescription queryDesc){
   var query = World.Query(queryDesc);
   foreach(var archetype in query.GetArchetypeIterator()){
      // Check the componentTypes inside the archetype to determine whether any of them inherit from T (the interface);
      // Loop over chunks to do something with the entities. There is information about this in the wiki
  }
}

But i would actually just get rid of thinking in OOP, seperate your data and remove the need of interfaces and act on the components you need in systems instead ^^

[Mathetis]

Interfaces are still very valuable for decoupling behavior, necessary for more effective, compositional testing. Object oriented programming in terms of inheritance (is-a) is not compatible with composition, but separation of concerns with interfaces for objects in 'has-a' relationships is still fundamentally compositional. One thing I will need to work around here is how types are concretely coupled together. It's not about separating data and behavior in my view -- effective testing means reducing cyclomatic complexity, and both data oriented programming that is tightly coupled and object oriented using inheritance will increase complexity quite a bit for sophisticated state machines.

In the case of Arch, this tight coupling is mitigated a bit for me. I am just going to query the concrete components (which are effectively like value type domain objects), and the 'system' will function as a composition root or aggregate that will use an injected service object interface. I want to totally separate the behavior of the system per entity from the query and enumeration over entities (separation of concerns), and I want to be able to test every interesting behavior in the aggregate for each system at the best level of testing.

Edit: clarified my comment on inheritance.