Jumping in here because i was curious about the same thing... i went
back to the docs for Actors, specifically this part about recommended
practices using Props:
http://doc.akka.io/docs/akka/2.3.7/scala/actors.html#Recommended_Practices.
from the fine documentation:
"It is a good idea to provide factory methods on the companion object of
each Actor which help keeping the creation of suitable Props as close to
the actor definition as possible. This also avoids the pitfalls
associated with using the Props.apply(...) method which takes a by-name
argument, since within a companion object the given code block will not
retain a reference to its enclosing scope"
Rationale 1 (keep Props definition close to the Actor definition) makes
a lot of sense. the more places you sprinkle Props.apply() around, the
more places you can get the apply parameters wrong. Props.apply is
defined as def apply(clazz: Class[_], args: Any*): Props, which takes a
varargs array of type Any, so you lose the benefits of type checking
when you call it. Its much better to wrap that apply in a factory
method where you can do type checking.
Rationale 2 is, i think, more of an historic artifact. there is another
definition for Props.apply, and that is: def apply[T <: Actor](creator:
⇒ T)(implicit arg0: ClassTag[T]): Props. the creator parameter is the
call-by-name argument referenced in the documentation, and it's a zero
argument function that returns an instance of type T, where T must be a
subtype of Actor. once upon a time, this was the only way to pass
constructor arguments to the Actor (see for example the definitions for
Props.apply in akka 2.1.4:
http://doc.akka.io/api/akka/2.1.4/?_ga=1.244187330.670637793.1404768069#akka.actor.Props).
there is a danger in using this mechanism, however: it is easy to
accidently close over unwanted state. If you do this within an Actor,
you may close over private actor state. Thus, defining your Props
factory in the companion object isolates you from this possibility.
I hope this was as edifying for you as it was for me :)
-Michael
On 12/08/14 14:35, Kane Rogers wrote:
Thanks, Andrew! This was super helpful to me!
Sorry for the newbie question, but why do we define a companion object
for MainActor, and create the props that way? What benefit does this
give us?
On Wednesday, 26 November 2014 01:23:40 UTC+11, Andrew James Ramirez
wrote:
Hi,
What is the best way to do this? Currently what I'm doing is
|
classMainActor(Dependency1:ActorRef, Dependency2:ActorRef)={
defreceive ={
caseTestMessage=>
Dependency1!"Test"
}
}
objectMainActor{
def
props(Dependency1:ActorRef,Dependency2:ActorRef)
=Props(classOf[MainActor],Dependency1, Dependency2)
}
|
|
val dependency1 = system.actorOf(Dependency1.props())
val dependency2 = system.actorOf(Dependency2.props())
val mainActor =
system.actorOf(MainActor.props(dependency1, dependency2))
mainActor ! "TestMessage"
|
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.