Functions aren't serializable, they can't be sent across the network so
this would break location transparency.
Perhaps with spores/SIP-21 you could shoehorn something in but there still
seem to be a lot of pitfalls. And of course I don't think there's anything
similar for the Java API.
To me, it just seems like a way to exacerbate the whole "closing over
sender/mutable state" problem actors already have with futures.
On Friday, August 21, 2015 at 11:34:13 PM UTC-6, kraythe wrote:
>
> Greetings,
>
> When I look at standard examples with Akka we always see very specific
> typed actors that handle messages of a certain type and return certain
> values. This tends to lead to big recieve methods with large amounts of
> code in them or a plethora of helper messages. I got to thinking about why
> we didn't simply package up the functionality inside the message as a means
> to implement the code. Its a slightly different architecture but might have
> some merits and I wanted to get your comments on it. For reference consider
> the following:
>
> case class DoSomethingMessage(msg: String)
>
> class SomeActor extends Actor {
> val log = Logging(context.system, this)
>
> override def receive: Receive = {
> case DoSomethingMessage(msg) =>
> log.info(s"Message had ${msg.length} chars and had text '$msg'")
> // do other stuff
> sender ! "thanks"
> case msg => log.error(s"received unknown message of type ${msg.getClass}")
> }
> }
>
>
> This is the standard way things are done. Now imagine that the do other
> stuff is performing 30 lines of code to accomplish something. However,
> consider the following architecture:
>
> case class DoSomethingElseMessage(msg: String) extends
> Function1[LoggingAdapter, String] {
> override def apply(log: LoggingAdapter): String = {
> log.info(s"Message had ${msg.length} chars and had text '$msg'")
> // do other stuff
> "Thanks"
> }
> }
>
> class SomeOtherActor extends Actor {
> val log = Logging(context.system, this)
>
> override def receive: Receive = {
> case f: Function1[LoggingAdapter, _] =>
> sender ! f.apply(log)
> case msg => log.error(s"received unknown message of type ${msg.getClass}")
> }
> }
>
>
> This is interesting to me because I can define specific untyped actors
> that simply process 'smart' messages sent to them and to accomplish the
> task they execute the code in the apply method. The concept can be extended
> to any other type of Callable, Runnable, or Function you wish. This would
> allow the actors to be generic and isolate the code to the messages. What
> is more the messages could be declared inside domain objects and thus have
> access to private internals of the class. This would allow the messages to
> do certain things while denying that functionality to other users. Finally
> it would allow me to cut down on the number of case blocks in the actor in
> the case of having hundreds of different message types (which on occasion
> we do.)
>
> So is there any reason why such an architecture would be a bad thing? I
> know you would not get some of the become() functionality of the actor but
> such things could be done in specialized subclasses of this actor if they
> are needed for the particular use case. Again that would mean that we can
> reduce the number of handlers to only these special messages.
>
> Comments on the idea? Id love to hear from those with a lot more Akka
> experience than I.
>
--
>>>>>>>>>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
