Roland Kuhn

@viktorklang Yes, that was my plan: just use an Executor and be done with it.

Do these concerns really need more than a stable Runnable? My plan is that ActorCell extends Runnable directly. Then a stupid Executor is enough but a smart one has all...

The result of trying the “minimal” rewrite approach can be seen in akka/akka#21128. It is quite large since it is a fully working implementation that covers all the ground that...

Actors always are characterised by their behavior, in `akka-actor` this is a `PartialFunction[Any, Unit]`. If you want to group related behaviors you put them into the same class or object,...

I would have loved to join you in Vilnius! But I guess one cannot always win … First the good ones: * getting rid of preStart sounds reasonable at first...

@ktoso We are talking about a handful of characters of boilerplate code. For purpose of ignoring naming for now, assume a factory method `makeActor`. ~~~scala makeActor[Command] { case (ctx, Ping)...

~~~scala scala> object A { def f(x: Int => Int)=42; def f(x: (Int, Int) => Int)=43 } defined object A scala> A.f(x => x) res3: Int = 42 scala> A.f((x,...

Sounds very good, with one exception: I think PreStart can and should be dropped because using Deferred is the right thing to do. When creating actors during construction, the resulting...

Johannes, I am not sure how, but we are definitely talking past each other. Deferred and withContext have exactly the same signature and semantics, do they not? Where is the...

Ah, I see, we are splitting hairs ;-) Because 1. this is not true (if every recipient of a new Behavior applies `Behavior.preStart` to it—which is the wart I was...