Hi Robert, this proposal shares some commonality with another experiment of mine, see https://github.com/akka/akka/pull/18147#discussion_r37143815 <https://github.com/akka/akka/pull/18147#discussion_r37143815>. The biggest conceptual issue here is that messages are deliberately separated from behavior in the Actor Model: an Actor reacts to messages when it wants and in whichever way it wants, this is key to achieve protocol compositionality (e.g. forwarding, aggregating, caching, etc.). What you describe is no longer an Actor, it is just a queue of functions to be run by an Executor.
Another angle is that placing the implementation within the message type means that this message is bound to a particular Actor type (and its internal state representation). How would you handle this message within another Actor that happens to speak (part of) the same language? The freedom to interpret the message at the receiving end is precisely what achieves the loose coupling in message-oriented systems. So, while it is certainly possible to place the code wherever you want, in general—or conceptually—the behavior belongs to the processing entity, not to the message. Regards, Roland > 23 aug 2015 kl. 16:39 skrev kraythe <kray...@gmail.com>: > > Sure I could do all of that. If the whole codebase was Scala. Its not. Its a > hybrid of scala and java. Even with just java I could do method delegation. > However, that kind of misses the point. > > Say we have domain object with the name Customer. There are certain messages > we send customer to debit their balance, change name, etc. But there are > other messages that we send to generate JSON specific to a particular rest > endpoint. It seems problematic at best to mix together the customer > implementation with the implementation to get the JSON data for that > particular endpoint. I would rather put the JSON creation in a callable and > pass it to the CustomerActor and then inside there we extract the relevant > fields for the JSON to return to the user. > > But even excluding this use case, consider a large domain object with 60 > different methods that can be done with it. You can order supplies, change > relevant information and so on. Now in order to implement this with an actor > I would have to make one HUGE 60 case message switch. Now, other than the > fact that it wouldnt be an efficient method (pattern matching 60 cases) it > would be really super annoying to see this massive method just to call some > other method. It would seem to be a lot clearer if the message is smart. So > when user calls Customer.placeOrder(Integer, Order) it would generate a Smart > message that has the implementation of the message processing in the code. > > Naturally you would have to watch out for closing over, mutable state and all > the other potential pitfalls of messsaging systems. However, the > implementation would be clean. Inside the method, the message is generated > and dispatched. The user gets back a future if needed and the actor for that > domain object realizes it is a smart message and simply runs the apply > function inside the smart message. > > In that paradigm the actor receive method is smaller, the message > implementation is isolated to the PlaceOrder method and we dont have a 60 > case dispatch. > > -- Robert > > On Sunday, August 23, 2015 at 2:28:54 AM UTC-5, Martin Senne wrote: > typo: "ctor" has the "a" missing. should be "actor" of course. > > Am 23.08.2015 09:26 schrieb "Martin Senne" <martin...@googlemail.com > <javascript:>>: > Hi kraythe, > > first, you can use method delegation to untangle the "large" receive method. > > Second, you can wrap all these methods including the relevant part of the > receive method into a trait and mix that into your concrete ctor > implementation. > > Cheers, Martin > > Am 23.08.2015 09:14 schrieb "Patrik Nordwall" <patrik....@gmail.com > <javascript:>>: > How would it look like when the actor has state? How is the state updated? > How do you handle the message differently depending on the state? > > Regards, > Patrik > sön 23 aug 2015 kl. 04:56 skrev kraythe <kra...@gmail.com <javascript:>>: > Actually I am not talking about that. It's a simple concept of putting the > implementation of the message processor in the message itself. It's just a > different way to organize the code. > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: > >>>>>>>>>> https://groups.google.com/group/akka-user > >>>>>>>>>> <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+...@googlegroups.com <javascript:>. > To post to this group, send email to akka...@googlegroups.com <javascript:>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > -- > /Patrik > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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+...@googlegroups.com <javascript:>. > To post to this group, send email to akka...@googlegroups.com <javascript:>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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 > <mailto:akka-user+unsubscr...@googlegroups.com>. > To post to this group, send email to akka-user@googlegroups.com > <mailto:akka-user@googlegroups.com>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. Dr. Roland Kuhn Akka Tech Lead Typesafe <http://typesafe.com/> – Reactive apps on the JVM. twitter: @rolandkuhn <http://twitter.com/#!/rolandkuhn> -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
