Instead of defining a different AbstractMicrobe type for each model of chemotaxis, there could be a single Microbe type with a parameter C<:Chemotaxis and a field chemotaxis::C field which would wrap the entire chemotactic system of the microbe.
Rather than enforcing a structure to follow for new microbe types, it would then only be required for the Chemotaxis struct to follow some prescribed rules.
Such a refactoring might also make it easier to implement further behavioral traits down the road (e.g. chemokinesis, interactions...) and separate the integration of "internal states" from the motion itself.
Types, however, are an issue.
Fast execution requires the struct types to be concretely typed (which is also a problem for AbstractMotility right now), which means that each behavioral trait would need its own parameter if a generic interface is to be provided.
This will eventually lead to breaking changes whenever new traits with their own type have to be added, and will require Microbe to store a load of type parameters most of which are not going to be used simultaneously in typical scenarios.
This is probably not a good idea. The rewrite of motility types (#78) should provide a relatively robust interface and allow for efficient models without modifying the current implementation of chemotaxis
Instead of defining a different
AbstractMicrobe
type for each model of chemotaxis, there could be a singleMicrobe
type with a parameterC<:Chemotaxis
and a fieldchemotaxis::C
field which would wrap the entire chemotactic system of the microbe.Rather than enforcing a structure to follow for new microbe types, it would then only be required for the
Chemotaxis
struct to follow some prescribed rules.Such a refactoring might also make it easier to implement further behavioral traits down the road (e.g. chemokinesis, interactions...) and separate the integration of "internal states" from the motion itself.
Types, however, are an issue. Fast execution requires the struct types to be concretely typed (which is also a problem for
AbstractMotility
right now), which means that each behavioral trait would need its own parameter if a generic interface is to be provided. This will eventually lead to breaking changes whenever new traits with their own type have to be added, and will requireMicrobe
to store a load of type parameters most of which are not going to be used simultaneously in typical scenarios.