Consider using IMessage interface on messages. about protoactor-dotnet HOT 7 CLOSED

I guess I should write something over proto actor messaging for myself?

I have a CurrentSynchronizationContextDispatcher (I'm using this with WinForms :) ) I can add to extensions or something.

from protoactor-dotnet.

Proto.Actor allows POCO's to be used for messages in process. only between nodes there is the need for Protobuf.

from protoactor-dotnet.

I guess I mean, I'd like the code to enforce that messages know if there is going to be a reply or not. This way the code at compile time knows if a message should be used on Tell or Request.

It seems requiring messages to have an interface in C# is the best way to do this. I don't think it would affect protobuf though I don't know a lot about it.

from protoactor-dotnet.

I see the value in knowing whether an incoming message is expected to produce a reply or not, but I'm not sure if this is something I think Proto.Actor should be opinionated about. In a lot of applications it probably makes sense, but in some it might not. Also, whether there is going to be a reply or not it not necessarily so straight-forward, e.g. that could depend not only on the type of message, but also on which behavior the receiving actor currently has.

from protoactor-dotnet.

That sounds like a useful thing to have for people who do WinForms :D Maybe we should set up some sort of "contrib" or "extensions" section of the repo for things that are not part of the core library but still nice to have.

from protoactor-dotnet.

Forcing an interface on messages I feel could potentially make it harder to setup certain scenarios where you would end up wrapping objects in an IMessage just because you don't want to implement the IMessage interface on them.

from protoactor-dotnet.

Fair enough. I think I'll be starting an extensions library with this and some DI stuff. I can keep it separate or contribute here. I'll share when I have something going.

Thanks!

from protoactor-dotnet.