On Sat, Aug 26, 2017 at 8:10 PM, Roland Kuhn <goo...@rkuhn.info> wrote:
> Hi Sean,
>
> removing the self-type would not help: its function is only to ensure that
> every ActorRef also has an appropriate implementation, basically proving
> that the down-cast that is used in many places in the implementation will
> work out fine. In the end every ActorRef needs to support the sendSystem
> method (not equally sure about isLocal, due to missing remoting
> implementation).
>
> Patrik & team: what is your opinion on this? Should sendSystem become
> visible in order to make ActorRef implementable by user code?
>
That would mean that SystemMessage would also be public API. How far would
we go? Would the system message implementations also be public?
An alternative would be to provide an ActorRefStub in akka-typed-testkit:
abstract class ActorRefStub extends ActorRefImpl {
private[typed] final def sendSystem(signal: SystemMessage): Unit =
() // silently ignore
}
It would not support things like watch. When would one want to use that
instead of Inbox.ref?
btw, sendSystem is a horrible name, should be sendSignal or
sendSystemMessage
> In any case we should probably prominently point out that suitable stubs
> for ActorRef and ActorContext are provided in the form of Inbox and
> EffectfulActorContext, and that rolling your own is typically not necessary.
>
> On stubbing out ActorSystem or making it easier to override, I have mixed
> feelings: it is a quite complicated machine that is not easy to modify
> correctly—and it is also not easy to provide a stub that actually works,
> due to some semantic requirements. I completely understand that just
> counting calls to terminate() may seem to contradict my statement, but
> consider the other side of the coin: if ActorSystem were as you want it,
> then people would modify it also in cases where that is not appropriate.
>
> To answer your concrete question, a much easier way of ensuring correct
> shutdown would be to supply a function of type () => Unit to the actor
> that shall call it. Production code would supply () => system.terminate(),
> but the test could provide whatever you want.
>
> Regards,
>
> Roland
>
> 25 aug. 2017 kl. 04:01 skrev Sean Shubin <seanshu...@gmail.com>:
>
> I had a chance to look over the typed actors a bit more. Here is my
> feedback. Whether you agree or disagree, I hope you find it useful. I am
> still really excited about typed actors, the main reason I have been
> reluctant to switch to akka is that I was not willing to give up static
> typing.
>
> Behavior by itself is easy to test as long as you are not doing anything
> with ActorContext. I particularly like the separation of the management
> method to deal with lifecycle signals, from the message method to deal with
> messages.
>
> ActorContext can't be stubbed out because it leaks out the private classes
> InternalActorRef and ActorSystemImpl through its protected methods
> lookupRoot, guardian, and systemImpl.
>
> ActorRef can't be stubbed out because of the self type on
> internal.ActorRefImpl. I have already demonstrated issue with this in
> detail with my FooApp and BarApp examples in this thread. I did look up
> the ScalaDoc for ActorRefImpl, and while I think its fine to hide the
> sendSystem and isLocal methods, I do think that if these methods were
> pushed down into a class that inherits from ActorRef, rather than using a
> self type, that would make it easier to stub out ActorRef.
>
> ActorSystem has the same problem as ActorRef for the same reason, but it
> manifests much worse because the ActorSystem trait has so many more
> methods. To see why, consider writing a unit test to make sure an actor
> system is properly shut down once the program is finished. I want to test
> the code here:
> https://github.com/SeanShubin/concurrency-samples/blob/
> master/actor/src/main/scala/com/seanshubin/concurrency/samples/actor/
> CleanupActorSystems.scala
> It should be as easy as this:
> https://github.com/SeanShubin/concurrency-samples/blob/
> master/actor/src/test/scala/com/seanshubin/concurrency/samples/actor/
> CleanupActorSystemsTest.scala
> And from looking at this test it seems like it is, but look what I had to
> do to get to this point:
> On my dependency injection class I had to add another level of indirection
> val eventActorSystem: ActorSystem[Event] = ActorSystem("state", stateful)
> val eventActorSystemContract: ActorSystemContract[Event] =
> new ActorSystemDelegate[Event](eventActorSystem)
> I had to hide ActorSystem behind an interface
> https://github.com/SeanShubin/concurrency-samples/blob/
> master/actor/src/main/scala/com/seanshubin/concurrency/samples/actor/
> ActorSystemContract.scala
> And then delegate to the real ActorSystem
> https://github.com/SeanShubin/concurrency-samples/blob/
> master/actor/src/main/scala/com/seanshubin/concurrency/samples/actor/
> ActorSystemDelegate.scala
> That way, for testing I could start with a class where nothing is
> implemented:
> https://github.com/SeanShubin/concurrency-samples/blob/
> master/actor/src/test/scala/com/seanshubin/concurrency/samples/actor/
> ActorSystemNotImplemented.scala
> Then use that not implemented class as a base for my stub
> class ActorSystemStub extends ActorSystemNotImplemented[Event] {
> var terminateInvocationCount = 0
>
> override def terminate(): Future[Terminated] = {
> terminateInvocationCount += 1
> null
> }
> }
> Which I finally use in my test
> https://github.com/SeanShubin/concurrency-samples/blob/
> master/actor/src/test/scala/com/seanshubin/concurrency/samples/actor/
> CleanupActorSystemsTest.scala
>
> My impression is that most of these problems stem from exposing classes to
> the user that are too concrete. If we could push some of these
> implementation details like private clases and self types further down the
> inheritance chain, and remove the need for client code to have a compile
> time dependency on the implementation details, it would be much easier to
> stub out interactions and have fully unit-tested code.
>
>
> --
> >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://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 akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM
Twitter: @patriknw
--
>>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
