My first impulse is to see if the need for down casts can be designed away.
This would remove the contention between trying to enforce certain
implementation details while simultaneously hiding those same
implementation details from the user. However I am not familiar enough
with the design
On Sat, Aug 26, 2017 at 8:10 PM, Roland Kuhn 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
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
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.
I will take a look at the ScalaDoc for ActorRefImpl.
To answer your question about how I intend to test behaviors, let me
clarify that my concern was not about testing behaviors specifically.
I was starting out by testing my interactions with behaviors.
Hopefully I can illustrate what I mean with
Hi Sean,
thanks for discussing Akka Typed!
The design decision behind splitting the interface into a public and a private
part is documented in the ScalaDoc for ActorRefImpl: end users shall not ever
see the top two methods because there cannot possibly be a reason to use
them—but the
ActorRef has a self type of ActorRefImpl. This means that if I want to
fake/stub/mock an ActorRef for test purposes, I cannot because I am forced
to know about ActorRefImpl. Instead of users of ActorRef being forced to
only use the ActorRefImpl implementation, ActorRef should be a minimal