I didn't mean make it take a tuple, I meant make it a function that takes a
sender and *then* returns a partial function:
*def receive(sender: ActorRef) = {*
* case ... =>*
* case ... =>*
*}*
I guess the performance cost for doing this is that you have to allocate a
new partial function each time, but is it really that expensive? (Maybe the
answer is yes, I am asking out of ignorance)
On Mon, Mar 10, 2014 at 4:48 PM, √iktor Ҡlang <[email protected]>wrote:
> receive is a method that returns a PartialFunction. PartialFunctions don't
> take 2 params and you don't want to allocate/box a Tuple2 for each receive.
> On Mar 11, 2014 12:02 AM, "Haoyi Li" <[email protected]> wrote:
>
>> > in essence it means removing `sender` from Akka actors (which has also
>> other very welcome benefits concerning closing over things in Future
>> transformations)
>>
>> I always wondered: if the problem is all about unwanted closure over
>> mutable state, why not just make *sender* a parameter instead of a magic
>> global?
>>
>> *def receive(sender: ActorRef) = {*
>> * ...*
>> *}*
>>
>> Voila, no more incorrect use of *sender* inside of futures or props or
>> any of that stuff!
>>
>>
>> On Mon, Mar 10, 2014 at 3:01 PM, Alexandru Nedelcu <[email protected]
>> > wrote:
>>
>>> On Mon, Mar 10, 2014 at 9:11 AM, Roland Kuhn <[email protected]> wrote:
>>>
>>>> BTW: almost all Future combinators are not concurrent (as in
>>>> nondeterministic), Futures are therefore very useful for modeling
>>>> parallelism without the concurrency pain. I invite you to scrutinize
>>>> the scala.concurrent.Future API for non-determinism and then see for
>>>> yourself how that is reflected in the types.
>>>>
>>>
>>> Stating the obvious for Dr. Roland Kuhn :-), but in my opinion the
>>> difference between a Future[T] and an ActorRef is that actors are too
>>> low-level and general, whereas Future[T] is very specialized - the Future
>>> combinators simply assume that Future is a container for a Try[T] result
>>> that will be available either now or in the future, the actual moment being
>>> of no consequence for the combinators that simply guide you through the
>>> happy path.
>>>
>>> The problem with Future[T] is that it can't be applied for example on
>>> problems where streams and/or bi-directional communications are involved.
>>> An ActorRef can provide an awesome implementation for Future[T] instances.
>>> However, between an ActorRef and a Future[T], there is a need for
>>> abstractions in-between.
>>>
>>> I know there are already patterns and best practices for designing stuff
>>> with actors, but whenever I work with actors, somehow I always end up with
>>> fragile and tightly-coupled designs, precisely because I had to deal with
>>> low-level stuff. E.g. actor A sends a message to actor B, but actor B could
>>> crash, so now you're thinking of using an external queue that persists
>>> messages for actor B's return. But once that external queue is operational,
>>> now you're thinking of redundancy for actor B, so you actually want actors
>>> B1 and B2, but because you designed actor B as statefull, now you're
>>> thinking in terms of primary / backup nodes and maybe you want those
>>> messages to not be pulled out of that queue unless they were processed in a
>>> reasonable amount of time by the primary actor, or otherwise have a backup
>>> that takes over that responsibility. Or maybe you have stateless B actors,
>>> so round-robin dispatching is not a problem, yet the message processing
>>> itself is long and could crash, so maybe you want to try again later with
>>> another actor in case it didn't finish in a reasonable amount of time. Then
>>> you realize that actor A should maybe send the same or different messages
>>> to different actors, but then you realize that this is actually tight
>>> coupling and you actually want a channel on which actors could subscribe
>>> for the messages they are interested in. Or maybe you want your cluster to
>>> scale depending on the load, so you want to create actors dynamically
>>> depending on runtime stats, yet this is a far cry from bringing up HTTP
>>> servers dynamically in an AWS ELB environment, because it's more generic
>>> and those docs give me the creeps.
>>>
>>> Somewhere in that process, my head explodes, especially given that I
>>> haven't solved the first problem I always have, which is good future-proof
>>> design, because actors don't guide your implementation at all and many
>>> times it's totally non-obvious of what to do.
>>>
>>> Kudos on debating the deprecation of "sender". That's a step in making
>>> that interface more solid. I also await eagerly on your Reactive Streams -
>>> I do feel the need for an Rx streams implementation that also does
>>> back-pressure.
>>>
>>> --
>>> Alexandru Nedelcu
>>> www.bionicspirit.com
>>>
>>> PGP Public Key:
>>> https://bionicspirit.com/key.aexpk
>>>
>>> --
>>> >>>>>>>>>> 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.
>>>
>>
>> --
>> >>>>>>>>>> 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.
>>
> --
> >>>>>>>>>> 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.
>
--
>>>>>>>>>> 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.
