Multiple queries (alternate interface)

[Masterchef365]

Allows one to make multiple queries from a single system. See the multiple_queries example!

This is a breaking change. Queries now have names; individual queries are declared like so:

sched
    .add_system(Self::update)
    .query(Query::new("My Query Name")
        .intersect::<MyComponent>(Access::Write))
    .query(Query::new("My Other Query Name")
        .intersect::<MyOtherComponent>(Access::Write))
    .build();

Queries are then referenced by their name:

for key in query.iter("My Query Name") {
    // ...
}

[Masterchef365]

Why do we want to write the word Query twice to declare a query in general?

The reason for the change is that Query is useful as a data type that can be stored or manipulated, which is especially useful when making libraries. For example, one might have a library which provides a system, and that system may need a set of query parameters. The library can then have a function returning an appropriate Query.

As for the interface, I'm flexible on that. This way was the most straightforward compared to our original interface, but another possible API would be:

sched.add_system(Self::my_system, &[
    Query::new("My Query Name")
        .intersect::<MyComponent>(Access::Write),
    Query::new("My Other Query Name")
        .intersect::<MyOtherComponent>(Access::Write)
]);

There are lots of other ways to do this, so if you have ideas let me know!

[MrKangs]

Why do we want to write the word Query twice to declare a query in general?

The reason for the change is that Query is useful as a data type that can be stored or manipulated, which is especially useful when making libraries. For example, one might have a library which provides a system, and that system may need a set of query parameters. The library can then have a function returning an appropriate Query.

As for the interface, I'm flexible on that. This way was the most straightforward compared to our original interface, but another possible API would be:

sched.add_system(Self::my_system, &[
    Query::new("My Query Name")
        .intersect::<MyComponent>(Access::Write),
    Query::new("My Other Query Name")
        .intersect::<MyOtherComponent>(Access::Write)
]);

There are lots of other ways to do this, so if you have ideas let me know!

I personally think that this implementation makes more sense that you are creating an array of queries that inserting that queries into the system call. However, would it be possible (and I think it is possible, but not sure if I am grammatically correct or not) to this implementation?

let my_system_quries = [Query::new("My Query Name").intersect::<MyComponent>(Access::Write),
Query::new("My Other Query Name").intersect::<MyOtherComponent>(Access::Write)];

let my_system_2_query = [Query::new("My Another Query Name").intersect::<MyAnotherComponent>(Access::Write)];

sched.add_system(Self::my_system).add_query(&my_system_quries).subscribe::<Component>().build();

sched.add_system(Self::my_system_2).add_query(&my_system_quries).add_query(&my_system_2_query).subscribe::<Component>().build();

The change that I am asking is adding a new function called add_query function that will read the query list that is declare above. This implementation will not only reduce the long function line implementation for the engine schedule, but also separate the query so that the plugin developers will easily change the query and used the same query for multiple system calls.

Also, could it be possible to change the interface of the subscribe function as well to match the query interface/ui as well?