Dispatch traits aren't composable about parry

[Ralith]

If external crates are to composably define shapes that need to dispatch recursively (i.e. compound shapes similar to HeightField), then I don't see any alternatives to the original proposal. However, end-user ergonomics could be preserved by relegating the root_dispatcher argument to a trait for use only by shape implementers, and turning QueryDispatcher into a blanket-implemented trait that encapsulates the self.query(self, ...) dance, and provides a chain helper for composition. How does that sound?

[sebcrozet]

Hi! I feel like adding a root_dispatcher arguments to all dispatch methods are a bit too intrusive, and makes it weird to use by the end-user (who has do call something like dispatcher.distance(dispatcher, ...).

A more transparent way of doing this is through composition:

1. Change the existing DefaultQueryDispatcher to a:

struct BaseQueryDispatcher<'a, D> {
    root_dispatcher: &'a D
}

impl QueryDispatcher for BaseQueryDispatcher {
    fn distance(...) {
        // ...
        if let Some(c1) = shape1.as_composite_shape() {
            Ok(query::details::distance_composite_shape_shape(
                self.root_dispatcher, pos12, c1, shape2,
            ))
        }
        // ....
    }
}

2. Redefine a new DefaultQueryDispatcher that calls the BaseQueryDispatcher methods (to avoid code duplication):

struct DefaultQueryDispatcher;
impl QueryDispatcher for DefaultQueryDispatcher {
    fn distance(...) {
        let dispatcher = BaseQueryDispatcher { root_dispatcher: self };
        dispatcher.distance(...)
    }
}

And then you can write your own dispatcher that passes itself to the BaseQueryDispatcher.
That way there is no need to change the signature of the dispatcher trait methods.

[Ralith]

That does look better. It might take some creativity to make composing dispatchers ergonomic (so that independently implemented custom shapes can be used without the end user writing a ton of boilerplate), but I think it's tractable; I'll play with it.

[Ralith]

Consider two libraries that define custom compound shapes, and an application that wants to use both. Ideally the application, which does not itself define any custom shapes, should not have to implement QueryDispatcher. I don't think the revised proposal supports that, since there's no way for parry to provide for composition of recursive dispatch logic, unless I'm missing something.