Parameterising Actor with Message type?

On Wed, Dec 21, 2011 at 9:37 PM, Jiansen <jiansenhe@gmail.com> wrote:

Hi all,

In the current API, there is no restriction on the type of messages
that send to an actor.  As a result, actor developers need to handler
uninterested messages.  Shouldn't it be the sender's job to make sure
that the sending message could be understand by the receiver?

An improvement could be parameterising the Actor trait (e.g. trait
MyActor[M]) and related send operators (!, ?!, send, etc.) by the type
of message it expects to receive (M).  By doing this, only those
messages that have generic type M could be sent to instances of
MyActor[M].

Interestingly, trait Actor extends trait AbstractActor, which extends
trait OutputChannel[Any], which is parameterised (trait OutputChannel[-
Msg]).  I think there might be some reasons behind the relaxed
design.  Any suggestions on the design decision or a version of actors
parameterised in the above way?

Also, how do you encode the "sender"-field? And obtaining remote references?
Cheers,√ 

With thanks
Jiansen

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Hi Jiansen,

On Wed, Dec 21, 2011 at 9:37 PM, Jiansen <jiansenhe@gmail.com> wrote:

Hi all,

In the current API, there is no restriction on the type of messages
that send to an actor.  As a result, actor developers need to handler
uninterested messages.  Shouldn't it be the sender's job to make sure
that the sending message could be understand by the receiver?

In the face of "become", how would you encode that type signature? 

An improvement could be parameterising the Actor trait (e.g. trait
MyActor[M]) and related send operators (!, ?!, send, etc.) by the type
of message it expects to receive (M).  By doing this, only those
messages that have generic type M could be sent to instances of
MyActor[M].

That's called Typed Actors :-) 

Interestingly, trait Actor extends trait AbstractActor, which extends
trait OutputChannel[Any], which is parameterised (trait OutputChannel[-
Msg]).  I think there might be some reasons behind the relaxed
design.  Any suggestions on the design decision or a version of actors
parameterised in the above way?

That's Scala Actors
Cheers,√ 

With thanks
Jiansen

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Hi Viktor,

Are you answering my question in the context of the Akka framework
rather than the pure Scala library? I posted a similar question in
akka user list as well. Sorry for the confusion.

If you were referring the akka library, following are my responses;
Otherwise, could you please tell me related libraries you were
referring to?

> > In the current API, there is no restriction on the type of messages
> > that send to an actor.  As a result, actor developers need to handler
> > uninterested messages.  Shouldn't it be the sender's job to make sure
> > that the sending message could be understand by the receiver?
>
> In the face of "become", how would you encode that type signature?
>

Let the "current actor" that has type Actor[C] and the "become actor"
that has type Actor[B]. In your case, we are providing users a "union
actor" that has type Actor[S], where S is the super class of type C
and B.

By the way, I don't think parameterising the Actor trait limits the
extensibility as we could always introduce new subclasses of the
parameter type.

> > An improvement could be parameterising the Actor trait (e.g. trait
> > MyActor[M]) and related send operators (!, ?!, send, etc.) by the type
> > of message it expects to receive (M).  By doing this, only those
> > messages that have generic type M could be sent to instances of
> > MyActor[M].
>
> That's called Typed Actors :-)

I didn't find Typed Actors in Scala API. If you mean Typed Actors in
Akka, then its way of sending messages is via calling methods, the
type of whose parameters are checked by the compiler. Sending
messages via calling methods rather than using !-like operators is
another pattern I would like to encourage.

> > Interestingly, trait Actor extends trait AbstractActor, which extends
> > trait OutputChannel[Any], which is parameterised (trait OutputChannel[-
> > Msg]).  I think there might be some reasons behind the relaxed
> > design.  Any suggestions on the design decision or a version of actors
> > parameterised in the above way?
>
> That's Scala Actors

Yes, I am describing Scala Actors in the question. What I don't know
is why OutputChannel has a type parameter (which suggests that type
parameter is important to an OutputChannel) while its subclasses
discard that type parameter (which suggests that type parameter is no
longer important to those subclasses).

> Also, how do you encode the "sender"-field? And obtaining remote references?

Do you mean Actor.self.sender : Option[ActorRef] in Akka?

Emm ... maybe we should have Actor[-M,+R](implicit manifestM:
Manifest[M], manifestR: Manifest[R]) and ActorRef[-M,+R](implicit
manifestM: Manifest[M], manifestR: Manifest[R]). If an actor has type
Actor[M, R], its "sender"-field will have type ActorRef[R,Any].
Moreover, the "sender"-field only be updated when the message is sent
via a synchronous request. Ohh..., I'm need to change more
implementations.

Cheers

Jiansen

Hi Jiansen,

On Wed, Dec 21, 2011 at 11:13 PM, Jiansen <jiansenhe@gmail.com> wrote:

Hi Viktor,

Are you answering my question in the context of the Akka framework
rather than the pure Scala library?  I posted a similar question in
akka user list as well.  Sorry for the confusion.

GMail kindly bundled your emails into one and applied my Akka-label to it, so my responses are from an Akka perspective. 

If you were referring the akka library, following are my responses;
Otherwise, could you please tell me related libraries you were
referring to?


> > In the current API, there is no restriction on the type of messages
> > that send to an actor.  As a result, actor developers need to handler
> > uninterested messages.  Shouldn't it be the sender's job to make sure
> > that the sending message could be understand by the receiver?
>
> In the face of "become", how would you encode that type signature?
>

Let the "current actor" that has type Actor[C] and the "become actor"
that has type Actor[B].  In your case, we are providing users a "union
actor" that has type Actor[S], where S is the super class of type C
and B.

But is a bind, in place. Essentially making the actor identity (the ref, change value) 

By the way, I don't think parameterising the Actor trait limits the
extensibility as we could always introduce new subclasses of the
parameter type.

The problem is with the identity, the reference. 

> > An improvement could be parameterising the Actor trait (e.g. trait
> > MyActor[M]) and related send operators (!, ?!, send, etc.) by the type
> > of message it expects to receive (M).  By doing this, only those
> > messages that have generic type M could be sent to instances of
> > MyActor[M].
>
> That's called Typed Actors :-)

I didn't find Typed Actors in Scala API.  If you mean Typed Actors in
Akka, then its way of sending messages is via calling methods, the
type of whose parameters are checked by the compiler.  Sending
messages via calling methods rather than using !-like operators is
another pattern I would like to encourage.

Yes, I'm talking about Akkas Typed Actors, which sacrifice "become" for statically verified interface. 

> > Interestingly, trait Actor extends trait AbstractActor, which extends
> > trait OutputChannel[Any], which is parameterised (trait OutputChannel[-
> > Msg]).  I think there might be some reasons behind the relaxed
> > design.  Any suggestions on the design decision or a version of actors
> > parameterised in the above way?
>
> That's Scala Actors

Yes, I am describing Scala Actors in the question.  What I don't know
is why OutputChannel has a type parameter (which suggests that type
parameter is important to an OutputChannel) while its subclasses
discard that type parameter (which suggests that type parameter is no
longer important to those subclasses).

> Also, how do you encode the "sender"-field? And obtaining remote references?

Do you mean Actor.self.sender : Option[ActorRef] in Akka?

Emm ... maybe we should have Actor[-M,+R](implicit manifestM:
Manifest[M], manifestR: Manifest[R]) and ActorRef[-M,+R](implicit
manifestM: Manifest[M], manifestR: Manifest[R]).  If an actor has type
Actor[M, R], its "sender"-field will have type ActorRef[R,Any].
Moreover, the "sender"-field only be updated when the message is sent
via a synchronous request.  Ohh..., I'm need to change more
implementations.

The rabbit hole goes deep. 

Cheers

Jiansen

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

I could see something like this working if we first got everything working with Actor[Any] and ActorRef[Any] (which would be what we have now), and then improving on that where we can.
For instance, the become method would be limited to the type parameter for the actor, so if all of the actor's messages were based on a Message trait, we could have an Actor[Message] where we could use become(behavior: PartialFunction[Message, Unit]).
It might be possible to implement this on top of what Akka currently offers. If we had a TypedMessage[_] trait, and used a wrapper around actorOf that returned a TypeMessageActorRef[_] you would be half way to a basic implementation. All that would be required is a wrapper around the receive method in the actor that took advantage of this, and special methods to send messages to these actors that respected type safety.
I personally would also like to implement an actor trait where the type of the state is also encoded into the actor. Then our receive method could become 'def receive(Message, State): State', which looks awfully familiar :) The FSM trait does something similar, but I'd like something a bit simpler. This could be taken further to be 'def receive(Message, State, Context): State' and that would solve problems with the current mutable context being captured by closures.
The great thing is that all of this can pretty much be done on top of what is already there.
--
Derek Williams

2011/12/21 √iktor Ҡlang :
> Hi Jiansen,
>
> On Wed, Dec 21, 2011 at 11:13 PM, Jiansen wrote:
>>
>> Hi Viktor,
>>
>> Are you answering my question in the context of the Akka framework
>> rather than the pure Scala library?  I posted a similar question in
>> akka user list as well.  Sorry for the confusion.
>
>
> GMail kindly bundled your emails into one and applied my Akka-label to it,
> so my responses are from an Akka perspective.

LOL :-P

>
>>
>>
>> If you were referring the akka library, following are my responses;
>> Otherwise, could you please tell me related libraries you were
>> referring to?
>>
>>
>> > > In the current API, there is no restriction on the type of messages
>> > > that send to an actor.  As a result, actor developers need to handler
>> > > uninterested messages.  Shouldn't it be the sender's job to make sure
>> > > that the sending message could be understand by the receiver?
>> >
>> > In the face of "become", how would you encode that type signature?
>> >
>>
>> Let the "current actor" that has type Actor[C] and the "become actor"
>> that has type Actor[B].  In your case, we are providing users a "union
>> actor" that has type Actor[S], where S is the super class of type C
>> and B.
>
>
> But is a bind, in place. Essentially making the actor identity (the ref,
> change value)
>
>>
>>
>> By the way, I don't think parameterising the Actor trait limits the
>> extensibility as we could always introduce new subclasses of the
>> parameter type.
>
>
> The problem is with the identity, the reference.
>
>>
>>
>> > > An improvement could be parameterising the Actor trait (e.g. trait
>> > > MyActor[M]) and related send operators (!, ?!, send, etc.) by the type
>> > > of message it expects to receive (M).  By doing this, only those
>> > > messages that have generic type M could be sent to instances of
>> > > MyActor[M].
>> >
>> > That's called Typed Actors :-)
>>
>> I didn't find Typed Actors in Scala API.  If you mean Typed Actors in
>> Akka, then its way of sending messages is via calling methods, the
>> type of whose parameters are checked by the compiler.  Sending
>> messages via calling methods rather than using !-like operators is
>> another pattern I would like to encourage.
>
>
> Yes, I'm talking about Akkas Typed Actors, which sacrifice "become" for
> statically verified interface.
>
>>
>>
>> > > Interestingly, trait Actor extends trait AbstractActor, which extends
>> > > trait OutputChannel[Any], which is parameterised (trait
>> > > OutputChannel[-
>> > > Msg]).  I think there might be some reasons behind the relaxed
>> > > design.  Any suggestions on the design decision or a version of actors
>> > > parameterised in the above way?
>> >
>> > That's Scala Actors
>>
>> Yes, I am describing Scala Actors in the question.  What I don't know
>> is why OutputChannel has a type parameter (which suggests that type
>> parameter is important to an OutputChannel) while its subclasses
>> discard that type parameter (which suggests that type parameter is no
>> longer important to those subclasses).
>>
>> > Also, how do you encode the "sender"-field? And obtaining remote
>> > references?
>>
>> Do you mean Actor.self.sender : Option[ActorRef] in Akka?
>>
>> Emm ... maybe we should have Actor[-M,+R](implicit manifestM:
>> Manifest[M], manifestR: Manifest[R]) and ActorRef[-M,+R](implicit
>> manifestM: Manifest[M], manifestR: Manifest[R]).  If an actor has type
>> Actor[M, R], its "sender"-field will have type ActorRef[R,Any].
>> Moreover, the "sender"-field only be updated when the message is sent
>> via a synchronous request.  Ohh..., I'm need to change more
>> implementations.
>
>
> The rabbit hole goes deep.
>
>>
>>
>>
>> Cheers
>>
>> Jiansen
>
>
>
>
> --
> Viktor Klang
>
> Akka Tech Lead
> Typesafe - Enterprise-Grade Scala from the Experts
>
> Twitter: @viktorklang
>