Databases
StackOverflow2013
Postsdbo
POAre there any hidden downsides to wrapping an Akka ActorRef in a thin wrapper class?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POAre there any hidden downsides to wrapping an Akka ActorRef in a thin wrapper class?
    primarykey
    data
    text
    <p>Being one for strong-typing and letting the compiler do the work (rather than "hoping" I remember), I'd like to use types other than just ActorRef for my akka-based library.</p> <p>Is there any sort of penalty for doing this? Basically, the wrapper would just implement the same methods (tell, ask, etc...) and just forward it directly to the actor and hold the ActorRef so I can have a strongly-typed facade.</p> <p>If anyone has any insights that would be great. I'm not familiar enough concurrent programming or the actors model to know if this is going to somehow slow things down.</p> <p>Edit: Here's some code samples as requested below.</p> <p>For example. Normally I'd do this in Akka.</p> <pre><code>val actor = context.actorOf(Props[Whatever]) </code></pre> <p>At this point, it is typed as an ActorRef. And so everything in my code has to work with ActorRefs. Is there any downside to doing the following instead...</p> <pre><code>class Wrapper(props: Props)(implicit context: ActorContext) { val actor = context.actorOf(props) def ! (message: Any):Unit = { actor ! message } //insert a direct wrapper of other regular actor functions here. } </code></pre> <p>Then, it would be called and behave exactly like an actor except I could strongly-type my design. Because each Wrapper would be typed with the enclosing class.</p> <p>Does this have any downsides? I realize it isn't strictly necessary but leaving behind strong-typing is a bit bothersome.</p> <p>For me, what came to mind is if this class is going to be running on some set thread and keep the akka actors underneath from behaving as asynchronously as they normally would (swapping out with many sharing a thread pool and so on)... as I am assuming that behavior only occurs for actors and so my class may be setting somewhere else and bottlenecking things.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USDante Romero
    1. USDante Romero
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COI'd like to see a more detailed explication (code) of your concept. I suspect it's not really workable, at least not beyond very simple and highly restrictive cases.
      singulars
      1. POAre there any hidden downsides to wrapping an Akka ActorRef in a thin wrapper class?
      1. USRandall Schulz
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload