Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extensible Shape dispatch. #303

Open
Ralith opened this issue Aug 18, 2019 · 1 comment
Open

Extensible Shape dispatch. #303

Ralith opened this issue Aug 18, 2019 · 1 comment

Comments

@Ralith
Copy link
Contributor

Ralith commented Aug 18, 2019

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 functions T, 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 concrete TypeIds.

@Ralith
Copy link
Contributor Author

Ralith commented Aug 18, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant