tustvold commented on issue #2175: URL: https://github.com/apache/arrow-datafusion/issues/2175#issuecomment-1262674648
> BTW, do you mean, it is impossible to declare a Trait and let it implements the PartialEq ? You can't do dynamic dispatch to a function that is parameterized on the concrete type - https://doc.rust-lang.org/reference/items/traits.html#object-safety > Here is a sample of how to make visit ExecutionPlan more generic and we can get ride of the visit pattern and tree traversing from the rule implementations I'm confused, if you're saying trait objects allow you to eliminate lots of dispatch logic, I 100% agree. Why then do you want to switch away from them? > I'm not sure why visiting a logical plan is a toss up Consider some function that takes a `LogicalPlan` and wants to perform some operation on `op()` on a set of variants `{var1...varn}`. If the set is small, both approaches are basically equivalent ``` fn do_fn(plan: LogicalPlan) { match plan { v1 => {...} v2 => {...} _ => } } ``` ``` fn do_foo(plan: dyn LogicalPlan) { if let Some(x) = plan.downcast_ref<v1> { ... } else if let Some(y) = plan.downcast_ref<v2> { ... } else { ... } } ``` However, as the set of variants grows the size of the enum dispatch logic grows linearly. Meanwhile with the `dyn LogicalPlan` we can "lift" op onto the trait as a method. ``` pub trait LogicalPlan { fn foo() { ... } } ``` We get the dispatch logic for free :tada: What I'm trying to suggest is that whilst structured matching is great, you pay for it by having to implement the dispatch logic yourself. You can hide it using visitor patterns, or using macros, but it never reaches the ease of trait objects where it is generated automatically. This means a one-size fits-all approach, may not make sense -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
