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.

Reply via email to