Is there any way to specify what type of message an actor can accept and give a compile error if anything tries to send it some other type?
Asked
Active
Viewed 1,180 times
12
-
1See also http://stackoverflow.com/q/5547947/158823 – mkneissl Apr 28 '11 at 05:19
-
Ah, that's definitely useful information, thanks! This link about [an excuse](http://article.gmane.org/gmane.comp.lang.scala/12988) is helpful, though I'm still not sure why nested receives requires untyped by default. Seems like it could still be done with types. – mentics Apr 28 '11 at 15:35
-
1At least from something I've read, apparently Scalaz has typed actors as well, so... sounds like the answer is don't use the actors in scala.actors, use one of the other options. – mentics May 18 '11 at 18:11
3 Answers
2
Not sure whether it answers your question, but I hope it will give you some ideas. Maybe you are searching for something like Typed Actors from Akka project:
The Typed Actors are implemented through Typed Actors. It uses AOP through AspectWerkz to turn regular POJOs into asynchronous non-blocking Actors with semantics of the Actor Model. E.g. each message dispatch is turned into a message that is put on a queue to be processed by the Typed Actor sequentially one by one.
So you define interface and implementation and then register them as actor. Akka will create proxy for your interface that still use actor model under the hood. And you still able to use following message passing styles:
- fire-and-forget
- request-reply
- request-reply-with-future
-
Although that does do what I'm talking about, it's more than what I'm looking for. I'm curious why it was chosen to have Actors take any object for a message send instead of having the actors take a type parameter or something so it could be type safe. – mentics Apr 28 '11 at 01:25
-
What would the type of the sender reference be? case class DoSomething(forwardTo: Actor[X]) <-- What is the X, and how do you escape the clutches of type erasure? – Viktor Klang Apr 28 '11 at 16:58
-
I'm not talking about the type of a sender reference, just the input message type. – mentics Apr 28 '11 at 18:14
-
But the sender reference is an ActorRef, and it needs to have the signature of the types of input, so what should be the signature of the sender reference, since the sender can be any ActorRef[_] – Viktor Klang Apr 29 '11 at 12:55
-
If I'm looking at the right place, Actor.sender is an OutputChannel[Any] and so it is a parameterized type already. – mentics Apr 29 '11 at 17:00
-
Well that is my point, then you're back to unityped, which was the thing you started with. – Viktor Klang May 01 '11 at 09:58
-
0
While typed actors do solve the problem to some extent, you have to keep in mind that this only provides partial static type safety — you are still silently doing a dynamic cast from an untyped actor to a typed one by that typedActorOf(...) call, and that's where the dynamicity creeps in and static correctness is lost — if the underlying ref turns out to point to an actor that does not actually obey the typed interface, you have a bug; Akka attempts no runtime verification of who's "backing" the typed ref so typed messages end up being sent to actors that can't (properly) respond to them.
All in all, to my best knowledge, the only way to go about achieving complete (?) static type safety with Akka is to use Typed Channels: http://letitcrash.com/post/45188487245/the-second-step-akka-typed-channels.
Erik Kaplun
- 37,128
- 15
- 99
- 111
0
I think the answer is in the post referred to by @mkneissl : "The common practice is to declare what messages an Actor can recieve in the companion object of the Actor, which makes it very much easier to know what it can receive."
An example of that would be useful...
