Hi Vitaly, > The solution I tried to implement is parameterizing a container by a sum of > traits including `Visitable<T>` trait. Then each item type in container > should implement the `Visitable<T>` trait to cast self to the required type > `T`. I thought it will allow me to use common implementation of the > `Visitor<T>` to transmute any collection which is parameterized by `.. + > Visitable<T>`. Unfortunately it doesn't work in stable Rust because trait > upcasting is experimental but looks like in principle this approach works.
I’m a little confused on the purpose of the generic T trait parameter on Visitable<T>. Are you wanting your container to contain a heterogeneous mix of T, or will T be the same for all objects in the container? In general, I’ve found there are only a few situations where generic parameters on traits make sense. Like the From / Into traits. Usually you want associated types or ideally no type at all if possible. Anyway, you can get around the lack of trait upcasting using an additional method in your other trait(s) along the lines of `as_visitable`. Check out this playground for an example. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c29675c8691d70e2078bce9f2a659f45 <https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c29675c8691d70e2078bce9f2a659f45> -Luke > On Dec 30, 2021, at 1:42 PM, Vitaly Bogdanov <[email protected]> wrote: > > Hi Luke, > > My topic at users.rust-lang.org is more about lifetimes and finally Alice an > Quinedot helped me to find the issues in my code. But I started writing this > implementation of the Visitor because I also found that it is impossible to > get the full information about type in Rust. Specifically having a trait > object one cannot downcast to another trait object which is implemented by > the type. Adding RTTI in Rust is probably a complex issue because new trait > can be implemented for a type even in separate library. Not adding RTTI from > the very beginning seems even logical and my question is if there are other > ways to implement functionality which requires such sort of operations. > > One example of the problem is transmuting the items in a heterogeneous > container. Container should be parameterized by some common trait but after > putting item into such container you cannot downcast the item to the > transmuting trait. Downcasting to the specific type is also a problem if this > type is generic and listing all type parameter values in advance is not > possible. > > The solution I tried to implement is parameterizing a container by a sum of > traits including `Visitable<T>` trait. Then each item type in container > should implement the `Visitable<T>` trait to cast self to the required type > `T`. I thought it will allow me to use common implementation of the > `Visitor<T>` to transmute any collection which is parameterized by `.. + > Visitable<T>`. Unfortunately it doesn't work in stable Rust because trait > upcasting is experimental but looks like in principle this approach works. > > It is similar to building upper bound for a set of types which are presented > in the container but I am not specifically interested in least upper bound > but it should be enough if upcasting work. I need to think about this further > and https://crates.io/crates/pergola is interesting from this perspective. It > can be event more useful for thinking about Hyperon type system. > > I posted another example of the issue at > https://stackoverflow.com/questions/70504911/how-to-implement-an-introspection-of-a-trait-content > . I suspect it also could be covered by `Visiable/Visitor` but when I am > tried to apply it I found that I need to parameterize `Plan<T, R>` by > additional `P0: Plan<(), R>` and I am not sure if it will compile and it > looks ugly. > > All of the issues above seem to be solvable by introducing some kind of RTTI. > Thanks for the link to https://crates.io/crates/rattish I am trying to stick > stable Rust compiler version but anyway it is worth to look at the code. I > also found https://docs.rs/query_interface/0.3.5/query_interface/ while > searching for the answer at StackOverflow. > > Thanks, > Vitaly > > > > -- > You received this message because you are subscribed to the Google Groups > "opencog" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/opencog/44db54de-f2f0-488d-a2f2-0fbb35367bdbn%40googlegroups.com > > <https://groups.google.com/d/msgid/opencog/44db54de-f2f0-488d-a2f2-0fbb35367bdbn%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/AC2A3FEC-B0CF-48EB-AC6A-005B0405F51B%40gmail.com.
