Receiver<M> support

[axos88]

Hi!

Is this a fork of actix with real async support? Seems to have a very similar api and feature set. One thing I'm missing is the receiver trait, which allows addresses to different actors that handle a specific message to be stored in a heterogenous list.

This would probably need moving the return type of the handler implementation to M: Message, which makes more sense, since currently it would be possible that two different actors return different types for the same message.

[axos88]

Ah I think message channel is that I'm looking for. Any reason this is a struct and not a trait?

[thomaseizinger]

Ah I think message channel is that I'm looking for. Any reason this is a struct and not a trait?

See #102. It ends up being a cleaner API and allowed us to implement broadcasting for them.

[thomaseizinger]

Is this a fork of actix with real async support?

It started as a fork yes but the codebases have massively diverged since.

We:

• don't have any unsafe code
• have a much smaller codebase and API surface
• got runtime-agnostic async support with proper backpressure

:)

[thomaseizinger]

This would probably need moving the return type of the handler implementation to M: Message, which makes more sense, since currently it would be possible that two different actors return different types for the same message.

This used to be the case and we moved away from it because it is a really quirky API. Any type can be a message now and what type to return is defined in the Handler impl on an actor. This makes a lot more sense given that the Handler impl itself defines the functionality, hence it should also say what that functionality evaluates too.

[thomaseizinger]

This would probably need moving the return type of the handler implementation to M: Message, which makes more sense, since currently it would be possible that two different actors return different types for the same message.

This used to be the case and we moved away from it because it is a really quirky API. Any type can be a message now and what type to return is defined in the Handler impl on an actor. This makes a lot more sense given that the Handler impl itself defines the functionality, hence it should also say what that functionality evaluates too.

It also enables #111 cleanly which we can hopefully ship some day :)

[axos88]

Thanks for the thorough answers. I did put my sherlock hat on, and found that it is still possible to put multiple actors that handle a specific message onto a collection as long as they return the same type as answers.

[thomaseizinger]

Thanks for the thorough answers. I did put my sherlock hat on, and found that it is still possible to put multiple actors that handle a specific message onto a collection as long as they return the same type as answers.

Glad you got it sorted!

Is there anything else or can we close this issue? :)