Actor upcasting/downcasting

[ducharmemp]

Hello! Fantastic crate, huge fan of the API and the similarities to projects like PonyLang!

I hate to resurrect a topic that's been beaten to death but I've been trying to figure out a way around this situation I've gotten myself into. For some background, I've convinced myself that a DOM implementation (and corresponding webview) is a Good Idea to try and implement in an actor based approach where each element in the dom is an actor instance. So far it's been an interesting mental puzzle so I'll just say it straight that I'm interested in this from a toy project perspective, rather than from a work perspective. That is to say, if the work or thought to answer this turns out to be incredibly complicated, feel free to tell me to shove off :)

So as you might know, the DOM is heavily specced out by C++ inheritance hierarchies due to projects like Chrome and Firefox. Servo has gotten around inheritance and rust limitations by doing some mem::transmute calls and repr(c). My brain tends to try and work more on the composing behaviors front due to a large amount of OOP in my day job, so my instincts tell me that I need a lot of traits.

Putting code down:

struct Node {
    first_child: ActorOwn<Box<dyn ActsAsNode>>>,
    last_child: ActorOwn<Box<dyn ActsAsNode>>>,
}

struct Element {node: Node}
struct HtmlElement { element: Element }
struct HtmlDivElement { html_element: HtmlElement }

trait ActsAsNode { ... }
trait ActsAsElement { ... }

impl ActsAsNode for HtmlDivElement {}

let actor = actor_of_trait!([cx], Box<dyn ActsAsNode>, HtmlDivElement::init(), ...) // Oops, we can't ever figure out what we originally had anymore

As you can see a Node has two pointers to the head/tail of its children. There are other pointers here for siblings to form a doubly linked list, omitted for brevity. A Node can have a child that is a) a text node, b) an html element, c) an svg element, etc etc, hence the usage of an erased type.

I've attempted to try and distill this down to something a bit more static but it's eluding me at the moment, so my current idea is that of casting between traits to coerce an dyn ActsAsNode into an dyn ActsAsElement, but you already know that doesn't work given rust's blocking issues with CoerceUnsized, upcasting, and unsized enum variants.

I suppose this is more of a general question aimed at figuring out what my options are, is this something that could (in theory) be supported by Stakker on stable or is this fundamentally not possible due to the blocking rust issues? I've found https://docs.rs/unsize/latest/unsize/ which purportedly brings unsized coercion to stable, but I don't know enough about unstable rust to vet its abilities.

[ducharmemp]

Ah it looks like #[derive(SmartPointer)] rust-lang/rust#123430 might be the faster up-and-coming feature to do these kinds of casts from/to dyn Traits

[uazu]

Thanks for the references to #[derive(SmartPointer)] and unsize. People will keep on coming across the need for these things, as I did, until someone eventually implements it. Right now I'm slowly recovering from Long Covid so I haven't been able to keep up with all this stuff.

Handling a DOM as actors seems interesting although slightly inefficient if calls have to cascade down the tree. I guess the point of using actors is to not look at the DOM as a static data structure, but rather as a living thing that has to respond to events and changes. It's an interesting idea. I wonder whether the actor separation may complicate things, i.e. actors can't peer into other actors' state. So if you need to know something about a parent or child, you'd have to call them asynchronously.

With ActorOwn<Box<dyn Trait>> you're saying you can't downcast. Downcasting is available if you have access to the vtable pointer, but that is wrapped by the actor. If you add methods to the trait to do downcasting, that should work. The methods in the vtable implementing the trait know the original type of the actor. So something like for_type::<T>(op: Box<dyn FnMut(t: &mut T)>). Maybe you could get this to work? This might be getting beyond what you can do with traits though. I've certainly used some tricks like this in the past successfully. The main thing is that the trait implementation knows the original type. However in this case, since this is executing in the actor context, it would have to run as an actor call.

The other alternative listed on my page is to make the trait external. Then you definitely can do downcasting. But it is more awkward in the code.

I guess the purpose of up/downcasting is to have an actor which optionally implements a whole set of different APIs. So what you really want is to be able to specify both the trait and the method, i.e. execute this method from this trait on this struct. It may be that the actor doesn't implement that method, in which case it would do nothing or return an error.

This problem is actually independent from the actor system. If you can create a "dispatcher" trait that does this job, of being able to attempt to run any method from any trait on a struct, then you could put it in an actor and it would work the same. So obj: Box<dyn Dispatcher>, then maybe something like obj.for_trait::<T>(|o| o.method(a,b,c)). However as I say maybe traits can't have methods with type arguments. I don't have time to experiment with this right now. Maybe you can find another way. Maybe the std::any::Any type might help. For example:

struct Dispatcher(Box<dyn Any>);
impl Dispatcher {
    fn run(&mut self, cx: CX![], cb: impl FnMut(o: &mut Box<dyn Any>)) {
        cb(*self.0, cx);
    }
}

So you'd create an ActorOwn<Dispatcher> which contains the actual actor as an Any. Then run gives you a way to run your callback method inside the actor call with access to the Any, to do whatever downcasting and calling you need to do. Maybe that could be made to work?