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" <[email protected] 
> <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" <[email protected] 
>> <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 <[email protected] <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/
>>>> >>>>>>>>>>      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] <javascript:>.
>>>> To post to this group, send email to [email protected] 
>>>> <javascript:>.
>>>> Visit this group at http://groups.google.com/group/akka-user.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> -- 
>>> /Patrik 
>>>
>>> -- 
>>> >>>>>>>>>> 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] <javascript:>.
>>> To post to this group, send email to [email protected] 
>>> <javascript:>.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
>>>>>>>>>>      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.

Reply via email to