Using Generic Functions as Component Properties?

[mirkoRainer]

I define a struct with generic function properties:

struct Condition<ConditionName, T, K>
where
    T: Fn(Entity, Commands) -> (),
    K: Fn(Entity, Commands) -> (),
{
    name: ConditionName,
    /// This will modify components on the Entity to remove the condition
    pub add_condition: T,
    /// This will modify components on the Entity to apply the condition
    pub remove_condition: K,
    pub applied: bool,
}

I then implement using closures:

impl<T, K> Condition<Flatfooted, T, K>
where
    T: Fn(Entity, &mut Commands) -> (),
    K: Fn(Entity, &mut Commands) -> (),
{
    fn new() -> Condition<Flatfooted, T, K> {
        let add_flatfooted = |entity: Entity, &mut commands: Commands| {
            eprintln!("{:?} is flatfooted.", entity);
        };
        let remove_flatfooted = |entity: Entity, &mut commands: Commands| {
            eprintln!("{:?} is no longer flatfooted.", entity);
        };

        Condition {
            name: Flatfooted,
            add_condition: add_flatfooted,
            remove_condition: remove_flatfooted,
            applied: false,
        }
    }
}

But then I'm unsure what to use when definining the Component using a Query:

[mirkoRainer]

Rusty in the Discord suggests:

Rusty: you are doing a generic system, so you need to apply a strict type for the queries(or use another generic), but eventually you will have to provide bevy a clear type in compile time
Rusty: you might be better off using dyn Trait objects(with boxes probably) so you will have only 1 strict type of Condition

[ManevilleF]

If you don't care what T and K are, use dyn.

[cart]

You can't pass in concrete type for these "generic function types" because they don't have a name. Instead, as long as you don't require capture closures, you can do this:

struct Condition<ConditionName>
{
    name: ConditionName,
    /// This will modify components on the Entity to remove the condition
    pub add_condition: fn(Entity, &mut Commands),
    /// This will modify components on the Entity to apply the condition
    pub remove_condition: fn(Entity, &mut Commands),
    pub applied: bool,
}

The benefit of that approach is that you can have a single system that runs different add/remove logic for each entity.

Depending on the context, you might be better served with something like this:

struct Condition<T: ConditionFunctions>
     applied: bool,
     condition: T,
}

trait ConditionFunctions {
  fn add_condition(entity: Entity, commands: &mut Commands);
  fn remove_condition(entity: Entity, commands: &mut Commands);
}

struct SomeCondition;

impl ConditionFunctions for SomeCondition {
  fn add_condition(entity: Entity, commands: &mut Commands) {
  }
  fn remove_condition(entity: Entity, commands: &mut Commands) {
  }
}

This locks you into a specific set of add/remove logic for Condition<T>, but it is more structured and allows you to tack on impls directly to your condition types.

[mirkoRainer]

Would ConditionImpl be ConditionFunctions here? Because it's using trait bound syntax?

Meaning the condition property of Condition is anything that implement ConditionsFunctions trait?

[cart]

Oops yeah forgot to rename that. Fixed!