Open Ralith opened 5 years ago
Given the potential complexity and diversity of dispatch logic, maybe the most pragmatic option is to define something like
pub trait Dispatcher<T> {
fn get(&self, a: &dyn Shape, b: &dyn Shape) -> Option<T>;
}
and use it more pervasively in the API. Then at least combinators can be defined for improved composition.
Presently, supporting a new shape requires defining a new
ContactDispatcher
, which is boilerplate-heavy, awkward to compose, and does not account for CCD or high-level query functions. This could be improved by relying something like on one or more dynamic containers that map(TypeId, TypeId) -> T
for various query functionsT
, and which can easily be mutated by the user to add new cases. However, implementation of some queries in terms of abstract interfaces like&dyn SupportMap
complicates this as the desired algorithm is associated with an unbounded set of concreteTypeId
s.