[akka-user] Parameterized return types on !! and !!!

[Viktor Klang]

Hey guys,

I've been thinking a lot on return type parameterized Futures and the Option[T] result type,
and I think we're moving in the wrong direction, the returnvalue type of a message is a dynamic problem, and it cannot be solved with statically typing the reply value.

A quick refresh:

val a = actor !! "foo" // What is the reply type?

val a : Option[FooMessage] = actor !! "foo" // What happens if we reply("pigdog")?

All in all we have like 4 different return conditions:

1) reply with the correct value within timeout
2) reply with an incorrect value within timeout
3) exception in receiver, re-thrown at sender
4) no reply within timeout

I've got like a bazillion different ideas goin in a bazillion different directions, so please, help me out here :-)

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Derek Williams]

I personally use Box from lift-common, makes it easy to do:

val a = (actor !! "foo").asA[FooMessage] ?~ "Invalid Response"

That will give me an empty response with a failure message if I don't receive a FooMessage.

My normal pattern is more like this:

for {

  a <- ((actor !! "foo") ?~ "Timed Out").asA[FooMessage] ?~ "Invalid Response"

  /* other processing here.... */

} yield result

In the case of a web service, I can also throw on a response code, like this:

for {

  res <- ((actor !! "foo") ?~ "Timed Out" ~> 500).asA[Option[FooMessage]] ?~ "Invalid Response" ~> 500

  foo <- res ?~ "Foo not found" ~> 404

} yield foo

That should cover your 4 possible responses (not sure about the exception though) as well as the possibility of a negative response in the case of looking up a value.

The symbols do take a little getting used to, and it isn't as clean as having it handle it automatically, but it does give you a lot of flexibility.

--
Derek

[Dustin Whitney]

Oh heavens!  Oh how I despise operators that convey no meaning.  However, that does look like a good solution to your problem... even if it makes my blood pressure rise.

Dustin

[Viktor Klang]

Thanks for your replies guys,

I've been tinkering with syntax like:

for(Some(r : ResultType) <- actor !! message) yield r

Downside is that !! need Option[Option[_]] result type

[Heiko Seeberger]

Hi,

On 12 May 2010 17:44, Viktor Klang <viktor...@gmail.com> wrote:

val a : Option[FooMessage] = actor !! "foo" // What happens if we reply("pigdog")?

I did not look into the sources yet, but if that's possible then the design is broken. IMHO static typing is all about making things like that impossible. Maybe reply must be parameterized in order to only allow for FooMessages in this example.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Stambecco, highly scalable computing: stambecco.org

[Heiko Seeberger]

Viktor,

On 12 May 2010 23:32, Viktor Klang <viktor...@gmail.com> wrote:

Downside is that !! need Option[Option[_]] result type

Sorry, but that's holy crap! Forget it, please.

The issue is, that reply is not parameterized. It boils down to the fact that Actors are not parameterized. If we add a parameter to Actors (Jonas, we already chatted about this at JAX) that determines the type of messages that can be sent to Actors, we know what we are allowed to reply.

IMHO this is not only a clean solution for this issue, but this is generally beneficial: Being able to restrict the set of messages that may be sent to an Actor. And this is not too intrusive, because we are free to set the parameter to Any.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Stambecco, highly scalable computing: stambecco.org

[Viktor Klang]

On Thu, May 13, 2010 at 9:59 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

Viktor,

On 12 May 2010 23:32, Viktor Klang <viktor...@gmail.com> wrote:

Downside is that !! need Option[Option[_]] result type

Sorry, but that's holy crap! Forget it, please.

The issue is, that reply is not parameterized. It boils down to the fact that Actors are not parameterized. If we add a parameter to Actors (Jonas, we already chatted about this at JAX) that determines the type of messages that can be sent to Actors, we know what we are allowed to reply.

IMHO this is not only a clean solution for this issue, but this is generally beneficial: Being able to restrict the set of messages that may be sent to an Actor. And this is not too intrusive, because we are free to set the parameter to Any.

The problem here is that the param for reply will be varying on the type of the actor or future to be replied to, so this is not a static problem, it's a dynamic problem.
 

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Stambecco, highly scalable computing: stambecco.org

--

You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

[Jonas Bonér]

This is a nice complement to the current Actor. But it can not replace it since it is extremely constrained.

That would mean that the Actor can only receive and reply with one single type of message.

Could be nice on and off but I never write actors like that in practice. I much rather have it stay as it is than imposing such a constrain.

If you need that then you could use the Agent which is typed to receive only one type of updating function.  
But parameterized actor would be a nice complement for the special case. I'll add that later.

--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner

On 13 May 2010 09:59, "Heiko Seeberger" <heiko.s...@googlemail.com> wrote:

Viktor,

On 12 May 2010 23:32, Viktor Klang <viktor...@gmail.com> wrote:
>
>

> Downside is that !! need Op...

Sorry, but that's holy crap! Forget it, please.

The issue is, that reply is not parameterized. It boils down to the fact that Actors are not parameterized. If we add a parameter to Actors (Jonas, we already chatted about this at JAX) that determines the type of messages that can be sent to Actors, we know what we are allowed to reply.

IMHO this is not only a clean solution for this issue, but this is generally beneficial: Being able to restrict the set of messages that may be sent to an Actor. And this is not too intrusive, because we are free to set the parameter to Any.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger

OSGi on Scala...

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To...

[Jonas Bonér]

Actors are very much dynamic in nature. That is why I like them.

--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner

On 13 May 2010 10:07, "Viktor Klang" <viktor...@gmail.com> wrote:

On Thu, May 13, 2010 at 9:59 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:
>

> Viktor,...

The problem here is that the param for reply will be varying on the type of the actor or future to be replied to, so this is not a static problem, it's a dynamic problem.
 

>
>
> Heiko
>
> Company: weiglewilczek.com
> Blog: heikoseeberger.name

> Follow me: twitter.com/hse...

--
Viktor Klang
| "A complex system that works is invariably

| found to have evolved from a simpl...

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To...

[Viktor Klang]

On Thu, May 13, 2010 at 10:18 AM, Jonas Bonér <jo...@jonasboner.com> wrote:

Actors are very much dynamic in nature. That is why I like them.

Me too :-)

My point was more like, since it's dynamic, then really, return types from !! and !!! should be made either Option[Any] or Option[_]
 
Of course we could add a DSL/util to do easy, typed, extractions

| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

[Jonas Bonér]

I agree. If we can't make it type safe then we shouldn't pretend that it is.
It will be type safe when we add parameterized Actor base class, but just for one type of return message. Then the user can choose.

--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner

On 13 May 2010 10:29, "Viktor Klang" <viktor...@gmail.com> wrote:

On Thu, May 13, 2010 at 10:18 AM, Jonas Bonér <jo...@jonasboner.com> wrote:
>

> Actors are very much...

Me too :-)

My point was more like, since it's dynamic, then really, return types from !! and !!! should be made either Option[Any] or Option[_]
 
Of course we could add a DSL/util to do easy, typed, extractions

>
> --
> Jonas Bonér
> http://jayway.com
> http://akkasource.com
> twitter: jboner
>>

>> On 13 Ma...

--

> You received this message because you are subscribed to the Google Groups "Akka User List" group.

> To post to this group, send email to akka...@googlegroups.com.

> To unsubscribe from this group,...

--

Viktor Klang
| "A complex system that works is invariably

| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: ...

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, sen...

[Heiko Seeberger]

On 13 May 2010 10:17, Jonas Bonér <jo...@jonasboner.com> wrote:

This is a nice complement to the current Actor. But it can not replace it since it is extremely constrained.

That would mean that the Actor can only receive and reply with one single type of message.

Could be nice on and off but I never write actors like that in practice. I much rather have it stay as it is than imposing such a constrain.

I'm misunderstood: I did not mean such a constrained design. Goad Rodeo (Stambecco) does it type safe, so I will look at the details there and hopefully come back with an understandable concept.

For the time being I agree that we should not pretend to be type safe => Use Any.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger

OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Stambecco, highly scalable computing: stambecco.org

[Jonas Bonér]

I know Goat Rodeo Workers. They are exactly like Akka Agents which is very different from Actors. In Agents you have a single memory slot and send a function to let update itself in-place. They are easy to do type safe.

--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner

On 13 May 2010 11:38, "Heiko Seeberger" <heiko.s...@googlemail.com> wrote:

On 13 May 2010 10:17, Jonas Bonér <jo...@jonasboner.com> wrote:
>

> This is a nice complement to the...

I'm misunderstood: I did not mean such a constrained design. Goad Rodeo (Stambecco) does it type safe, so I will look at the details there and hopefully come back with an understandable concept.

For the time being I agree that we should not pretend to be type safe => Use Any.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger

OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

Stambecco, hi...

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, sen...

[Dustin Whitney]

On Thu, May 13, 2010 at 4:55 AM, Jonas Bonér <jo...@jonasboner.com> wrote:

I agree. If we can't make it type safe then we shouldn't pretend that it is.
It will be type safe when we add parameterized Actor base class, but just for one type of return message. Then the user can choose.

My two cents: I like it the way it is, simply because it makes my code more concise.  In all cases where I've been awaiting either a future or a reply, it's a single type that should be returned, and dealing with a few more lines of pattern matching code seems unnecessary.  If the reply comes back as another type, an exception will be thrown, but if I didn't expect that type, it's unlikely my code will be written to handle unexpected replies anyway (i.e., I'll probably just log the fact that I got some unexpected message). 

Dustin
 

[Jonas Bonér]

On 13 May 2010 15:54, Dustin Whitney <dustin....@gmail.com> wrote:

On Thu, May 13, 2010 at 4:55 AM, Jonas Bonér <jo...@jonasboner.com> wrote:

I agree. If we can't make it type safe then we shouldn't pretend that it is.
It will be type safe when we add parameterized Actor base class, but just for one type of return message. Then the user can choose.

My two cents: I like it the way it is, simply because it makes my code more concise.  In all cases where I've been awaiting either a future or a reply, it's a single type that should be returned, and dealing with a few more lines of pattern matching code seems unnecessary.  If the reply comes back as another type, an exception will be thrown, but if I didn't expect that type, it's unlikely my code will be written to handle unexpected replies anyway (i.e., I'll probably just log the fact that I got some unexpected message). 

After thinking some I actually agree with Dustin. If we can't solve it better then I prefer the way it is. Now we at least get the API to do an ugly cast for us. Which can generate a runtime error in either case. Just cleaner code. 

--
Jonas Bonér

work:   http://jayway.com
code:   http://akkasource.com
blog:    http://jonasboner.com
twitter: @jboner

[Viktor Klang]

Alright, thanks for your input and valueable time

On May 13, 2010 7:27 PM, "Jonas Bonér" <jo...@jonasboner.com> wrote:

On 13 May 2010 15:54, Dustin Whitney <dustin....@gmail.com> wrote:
>
>
>

> On Thu, May 13, 2010 ...

After thinking some I actually agree with Dustin. If we can't solve it better then I prefer the way it is. Now we at least get the API to do an ugly cast for us. Which can generate a runtime error in either case. Just cleaner code. 

>
> Dustin
>  
>>
>> --
>> Jonas Bonér
>> http://jayway.com
>> http://akkasource.com

>> twitter...

--
Jonas Bonér

work:   http://jayway.com
code:   http://akkasource.com
blog:    http://jonasboner.com
twitter: @jboner

--
You received this message because you are subscribed to the Google Groups "Akka User List" ...