Hi Robert,
The problem with old Java domain objects IMHO is how to properly guard
their state, for example, you might think of solutions like Loading caches
using Guava or any other caching framework but that still doesn't free you
from mutability problems, caching is one of the hardest
Roland,
Sorry I got frustrated. Perhaps we I am just having problems communicating.
Back to the issue at hand. Your code sample is fine, and I like how its
implemented, but here is what I wonder. What is the difference between what
you wrote and having a message that implements Callable? Only
Hi Robert!
27 aug 2015 kl. 16:01 skrev kraythe kray...@gmail.com:
Roland,
Sorry I got frustrated. Perhaps we I am just having problems communicating.
That might well be, thanks for being open!
Back to the issue at hand. Your code sample is fine, and I like how its
implemented, but
Roland,
As is the case with 90% of software out of academia, there isnt much purity
of any pholosophy in the system. We have to deal with legacy code, code
implemented badly, code implemented by other teams and as a practical
matter of reality I cant advocate a complete refactor of an
Hello Robert,
Furthermore since a user could call the methods anyway on the domain
object why would a newer developer bother going through the actor anyway.
Oh yeah you can say code reviews but in a large team I don't have time to
review every line of code.
This is kind of the point- there is
Interesting but I cant keep all the customers in memory active as an actor.
I would need thousands of memory resident objects, many of which would
never be used. The customer is a domain object that contains data and is
loaded on demand. Furthermore, the Customer object is a Java object, not a
25 aug 2015 kl. 20:59 skrev kraythe kray...@gmail.com:
No I dont mean they close over the state at all. I mean they are nested. I
fail to see how it is any more than an organizational strategy and why it
would be considered bad. Nor do I see how it is a single threaded executor.
Hi Robert,
26 aug 2015 kl. 21:32 skrev kraythe kray...@gmail.com:
Interesting but I cant keep all the customers in memory active as an actor. I
would need thousands of memory resident objects, many of which would never be
used. The customer is a domain object that contains data and is
25 aug 2015 kl. 20:59 skrev kraythe kray...@gmail.com:
No I dont mean they close over the state at all. I mean they are nested. I
fail to see how it is any more than an organizational strategy and why it
would be considered bad. Nor do I see how it is a single threaded executor.
Roland,
All good points but if you look at large systems there are a large set of
messages that have a relatively static implementation. For example, go
fetch X from all objects of type Y in the system. There is little to be
interpreted in that message. With the book based examples, we could
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
No I dont mean they close over the state at all. I mean they are nested. I
fail to see how it is any more than an organizational strategy and why it
would be considered bad. Nor do I see how it is a single threaded executor.
Messages are still being sent. You are just taking advantage of the
Hi Robert,
25 aug 2015 kl. 19:51 skrev kraythe kray...@gmail.com:
Roland,
All good points but if you look at large systems there are a large set of
messages that have a relatively static implementation. For example, go fetch
X from all objects of type Y in the system. There is little
By the way you could always make a message that takes a customer as an
argument and pass 'this' to the message apply method if you don't want to
look it up the way I did.
On Tuesday, August 25, 2015 at 1:59:53 PM UTC-5, kraythe wrote:
No I dont mean they close over the state at all. I mean
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
15 matches
Mail list logo
