Generate methods that sends/asks per protocol cases.

[Swoorup]

Great library. I was comparing this crate between other actor libraries. And am tempted to built my next project using this.

Do you have thoughts on allowing something like the following which would further reduce some boilerplates (possibly in addition to existing), similar to https://lib.rs/crates/tractor ?

#[derive(Debug)]
#[protocol]
enum MyProtocol {
    #[msg(Request<String>)]
    Echo { from: String },
    MyMessage { number: u32 } ,
    Multiple(i64, String),
}

/// allows the following methods
address.send_my_message(4u32);
let response: String = address.ask_echo("Tom".into()).await;
address.send_multiple(4i64, "Hello".into())

This basically

• gets rid of the need to specify new struct for Request per enum case,
• the generated method [send|ask]_[snake_case_enum_discriminant_name] (perhaps there is no need for send/ask in the generated method names) can internally either await on rx for the response if the case is requestable, instead of the user having to wrap in a seperate struct to do it, simplifying the usage.
• All protocol request/response can be contained without needing to additionally declare other structs

[jvdwrf]

I get where this is coming from, and my (many :)) initial attempts at building an actor system were quite similar to what tractor does. This was a very deliberate though, to have to define a unique struct for every message. (You could probably group all messages in a project in a mod msg { struct Echo; struct Multiply; ... }

I know this can be verbose at times, but that is what allows you to cast 2 addresses of different types to the same type: They both accept messages of type T, and both respond with the same response. Building systems at scale becomes really hard if this is not possible, and therefore I have decided to take another route. More verbose but a better application seems rusty to me :)

It is technically possible to build this kind of system on top of zestors, and it could integrate okay with supervision etc, but you would lose the ability to have an Address<AcceptsAll![u32, u64, ...]>. (This would then allow automatic generation of a send/ask trait)

As for a send/ask trait without this additional layer, we would have to automatically generate a trait for every message which creates even more types. Not sure if that is worth it, but it is worth a try once there is a solid foundation to build upon.

[jvdwrf]

This was the first version :) Later on I also automatically generated methods for the address, so that you wouldn't have to write them by hand.

[jvdwrf]

With the new v0.1 release this should be possible now with the Protocol derive macro that generates these methods.

Does that resolve the issue?