* rename PersistentEffect to Effect
* change order of parameters, ctx first
* rename onEvent to applyEvent
* persistenceIdFromActorName for Cluster Sharding
* PersistenActor.immutable
Cleans up the API in a couple of places, but still needs type parameters
in spots where I wouldn't want to need them...
Allow multiple side effects in one 'andThen'
Making type inference actually work
Allow applying multiple side effects
In a way that allows 'inspecting' the effects if you want to, but
doesn't require you to repeat generic parameters when you don't.
* Expand example with a timer
* Move 'onRecoveryComplete' to 'builder' style
* rather than using a default parameter which is hard to
evolve with binary compatibility
* Explicit snapshots
* Example spawning a child actor
* Taking a snapshot needs access to the state
* Added signal handler
* I like how simple the types of `commandHandler` and
`signalHandler` are now, but it'd be nice if they were closer together and could perhaps even share the `state` switch. I'll give that a try.
* Attempt to get signal handling closer to command handling
* Always use the full state for snapshots
* If you want to add a mapping layer use event adapters or a custom
serializer.
* Example of an actor that separates 'persistent' and transient state
* Use ordering 'command, event, state, context' consistently
* Allow multiple `andThen`
* Replace ask with spawned adapters
* Allow 'andThen' on each PersistentEffect
* Make 'onSignal' a partial function
* Remove unnecessary parens
* Simplify 'andThen', make sure it receives the State
* a Receptionists extension
It's basically an improved copy of the former receptionist pattern which is
removed here as well.
* Cluster implementation using Distributed Data
* =typ make ActorRef.apply work for adapted actor systems
* Cluster management (join, leave, etc)
* Cluster membership subscriptions (MemberUp, MemberRemoved, etc)
* New SelfUp and SelfRemoved events
* change signature of awaitAssert to return the value (not binary compatible)
* Cluster singleton api
* =jdk9,str JDK9 ready classes, in special directories
* =str,jdk9 prepare for releasing using JDK9 (needs sbt 1.0+ though)
* =str,jdk9 passing TCK spec touching some JDK9 types internally
* make sure to include linting options
* =str move non-boilerplaty shapes out of templates
This will improve code navigation for those classes.
- FanInShape, FanInShape1N, UniformFanInShape
- FanOutShape, UniformFanOutShape
* =str deprecate FanInShape1N
It was not tested, used or documented anywhere. With one input of type T0,
n inputs of type T1 and one output of type O, it is also arguably not
particularly generic to warrant its inclusion.
* !str remove unnecessary copyFromPorts implementation in Fan{In,Out}Shape
Strictly speaking this is a binary incompatible change. It would only affect
users that explicitly called `copyFromPorts` (but for what reason?).
* =str #23636 fix deprecation message not to use backticks
Backticks break genjavadoc / unidoc.
Fixes#23636.
* add+use UniformFanOutShape#outSeq for consistency
UniformFanInShape has inSeq, whereas UniformFanOutShape has outArray.
There's probably no good reason for this discrepancy.
* 2.5.3 is gold, deprecation would start in 2.5.4
* specialize in/outlets where possible
* review comments, binary compatibility
* optimize imports
* use Array copy internally
* give FanInShape1N the deprecation treatment
also, s/T\d/I\d/g
* delete ignored file
* process additional review comments
* make inArray fully private everywhere
* add benchmark heavy on the use of FanInShape.in()
* benchmark says: do not use Array for most n
* add JavaDoc to un-final'ed defs to not override
* change deprecated val to def; do not use it
* process patriknw's review comments
