Actor spawing using: val vs lazy val vs normal method call

Question

Please take a look at the below code and explain the difference between different ways of spawning an actor in akka actor system. which is efficient and why?

Class Parent extends Actor{
    def createChild(props:Props,name:String)={
        context.actorOf(props,name)
    }
    val type1=createChild(ChildActor.props,"Child")
    lazy val type2=createChild(ChildActor.props,"Child")
    def receive={
        case x =>
        type1 !"someMessage"
        type2 ! "someMessage"
        createChild(ChildActor.props,"Child")  ! "someMessage
    }
}

Thanks in advance

Possible duplicate of [\`def\` vs \`val\` vs \`lazy val\` evaluation in Scala](http://stackoverflow.com/questions/9449474/def-vs-val-vs-lazy-val-evaluation-in-scala) — Yuval Itzchakov, Jan 11 '17 at 06:28
I think you should just avoid `lazy val` for an `Actor`. The reason being that in most cases you will probably want to be accessing your actor via an `ActorSelection` and not via that `ActorRef`. And in the cases of using `ActorSelection` that `lazy val actorRef` will never be actually created and thus your actor will not exist. — sarveshseri, Jan 11 '17 at 07:27
@SarveshKumarSingh Is the above explaination is valid for **val** also? — Suga Raj, Jan 11 '17 at 07:34
The difference between `val` and `lazy val` is that `val` are actually created there and then but `lazy val` are created only when a `non lazy` operation is performed on them and the run-time can no longer delay their creation. `ActorSelection` is an approach to get the handle for an `Actor` using its `address` (stays same on failure recovery) instead of the ephemeral `ActorRef`. And thus you may end-up without performing a `non-lazy` operation on that `lazy ActorRef` and thus your `Actor` may never actually get created. And your `ActorSelection` will keep on resulting without anything. — sarveshseri, Jan 11 '17 at 07:43
@SarveshKumarSingh Thank you for explaining the difference. Let me rephrase my question. It goes like this: **When and where we can use val to create a actor and when to us method to create an actor** . — Suga Raj, Jan 11 '17 at 07:56
This question actually does not make sense. A `def` can be seen as a computation block which will result in some `value` when executed. Where as a `val` is an `immutable reference` to an existing `value`. For example... lets say you like cooking and you have the habit of naming the cakes that you make. Now... a `val` can be though of being similar to the `name of cake` where as a `def` can be thought of being similar to the `process of making the cake`. This should have cleared the confusion. — sarveshseri, Jan 11 '17 at 08:03
@SarveshKumarSingh i understood that difference but i am trying to understand in the context of actors what difference it makes? Can you explain on that context?..something like **Creating an instance of an actor vs creating an new actor** — Suga Raj, Jan 11 '17 at 08:57
declaring a def => does nothing at runtime. declaring a val => create an actor at runtime declaring a lazy val => maybe create an actor or not at runtime, depending of run. — C4stor, Jan 11 '17 at 13:05
it makes NO DIFFERENCE. And what is even the meaning of `Creating an instance of an actor vs creating an new actor` ? You can not "create" a concept. Concepts don't "exist". Concepts enable us to define and rationalize other instances of existence. `Actor` is a concept like `the cake` is. Where as the instance of an Actor is like instance of a cake. — sarveshseri, Jan 11 '17 at 14:10
So the question should be boiled down to the behavior of an actor in the life cycle. He's not asking about the creation or behavior of vals vs lazy vals. He's asking about the granular details of the actor instantiation. Slight hint: lazy vals only get initialized once. Even with actor restarts. — monksy, Aug 14 '19 at 21:48

Actor spawing using: val vs lazy val vs normal method call

0 Answers0