Hi Leonid, Thanks for the reply!
1. Why do you say it is the same for PersistentActor? PA doesn't wrap incoming messages in its `receiveCommand`, so there is no confusion there. In fact, the first PA example in the documentation specifically has 2 different classes, `Cmd` and `Evt`, to differentiate between commands and events. The `Event` matcher comes from regular FSMs (which aren't event-sourced, so don't have this confusion). I agree it's not very important, but from personal experience trying to explain it to several people, it seems confuse them. So I wonder if it wouldn't be worth it to change this (or at the very least add an alias for it). 2. Sorry, I guess my question wasn't clear. I understand why the classTag is needed, I don't understand why it needs to be provided by the user or why it needs to be implicit. 3. Yeah, this is more or less what we settled on, thanks. Thanks, Tal On Friday, August 25, 2017 at 11:39:50 PM UTC+3, leonidb wrote: > > Hi Tal, > > > I've implemented the original Persistent FSM PR, I'll try to answer your > questions. > > > 1. > > The same is true for the regular PersistentActor, it probably wasn’t > important enough. > 2. > > It’s needed to handle the events on recovery. PersistentFSM saves 2 > types of events: state change events and domain events of type E. This > class tag was needed to pattern match the domain events on recovery. > 3. > > replying is defined in the regular FSM state and PersistentFSM tries > to follow the same contract/signiture. Instead you can use andThen for > this. It accepts the callback with a signature - nextData ⇒ Unit. See > this example: > http://doc.akka.io/docs/akka/2.5.3/scala/persistence.html#a-simple-example > > > Thanks, > Leonid > > On Wednesday, August 16, 2017 at 8:51:36 PM UTC+3, Tal Pressman wrote: >> >> Hi, >> >> We've been using Persistent FSMs for a while now, and really like them - >> the combination of the structure and functional state with event sourcing >> is really useful for us in many cases. >> >> However, there are some places where the API feels a bit strange, or that >> it's missing some things, and I would love to either understand the >> motivation/logic behind it (or to create a PR fixing them ^_^ ) >> >> 1. PersistentFSM uses the Event matcher from FSM. However, in >> PersistentFSM (and event sourcing in general), event already has meaning. >> I >> think it would be clearer if this was called Command. >> 2. implicit domainEventClassTag - this one is a constant source of >> trouble, and I don't really understand why it's there. The trouble is >> that >> when using IntelliJ, and telling it to generate overrides for >> unimplemented >> methods, the generated method declaration includes the 'implicit'. This, >> together with the usual implementation (classTag[Whatever]) causes an >> infinite recursion ending with stack overflow. At the same time, I don't >> understand why this method is even necessary. Wouldn't defining the Event >> type parameter as E: ClassTag be enough? >> 3. There are many cases where, in the state function, it would be >> useful to know what the "next data" would be. For example, consider an >> FSM >> with a state waiting for N responses and counting the received responses >> in >> the data. You would have to either duplicate the logic (here it's simple >> counting, but there are obviously more complex use-cases) or need access >> to >> the data after applying the generated event. Now, I understand why this >> is >> the way it is, and why it would be impossible (without access to a time >> machine) to properly "solve" this. So for deciding on which state to >> transition to, or which events to emit we have to accept it. However, >> there >> are some specific things (like the "replying" part of the state) where I >> think a more convenient API could be provided (replying could take a >> function from nextData => reply). >> >> (Yeah, this post should probably have come back when the persistent FSM >> API was being finalized, but better late than never?) >> >> Thanks, >> Tal >> >> -- >>>>>>>>>> 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.
