Unable to message another actor (can message self)

[Daklu]

David Staab wrote:

I cannot fathom any situation in which this is a good idea. None.

I can't think of any either, but it doesn't mean that situation doesn't exist.  Even if it is never a good solution from a software design standpoint, it may be an acceptable solution from a business standpoint.  We all incur code debt of one form or another.  The important thing is we understand we are adding to the debt while we are writing it and don't let it get out of hand.

[David_Staab]

Daklu wrote:

Even if it is never a good solution from a software design standpoint, it may be an acceptable solution from a business standpoint

Well duh, but it's faux pax to discuss the shortcuts and cheats we use when we're in a bind, especially when advising a newbie on how to approach a framework or design they aren't yet familiar with.

[tst]

David Staab wrote:

I cannot fathom any situation in which this is a good idea.

I didn't say it was a good idea. I said "legitimate solution".

David Staab wrote:

Calling those methods directly is likely to circumvent the intended design of the actor.

Yes, but if you look at the design of the AF, you see that an actor can work as a fully by-value class (which is a point AQ has made numerous times), so if you create a copy, you can read the stale data from that copy. Like I said, that doesn't mean it's a good idea (it probably never is and it's certainly a potential for bugs if you don't know exactly what you're doing), but it is possible. I most definitely would not recommend it for someone who doesn't understand the implications (I probably wouldn't recommend it to someone who does either, but I could possibly, although not likely, suggest it under certain circumstances). In this case, I wasn't the one who brought it up.

[David_Staab]

When a space unicorn materializes in front of me and whisks me away to an enchanted world filled with nutella sandwiches and free whiskey (also possible, however unlikely), then I'll entertain passing an AF actor object into another AF actor object so as to be able to access the first actor's methods as a legitimate design decision.

[Daklu]

David Staab wrote:

Well duh, but it's faux pax to discuss the shortcuts and cheats we use when we're in a bind...

LOL.  Regarding the faux pas, I agree we should guide newbies towards the "correct" way to design their actors.  I disagree discussing shortcuts and cheats among advanced developers is (or should be) a faux pas.  I think they should be discussed, with the caveat that it is clearly identified as a hack and creates code debt.  Ideally it would also describe the "correct" implementation and highlight some of the consequences of the hack.

David Staab wrote:

When a space unicorn materializes in front of me and whisks me away to an enchanted world filled with nutella sandwiches and free whiskey (also possible, however unlikely), then I'll entertain passing an AF actor object into another AF actor object so as to be able to access the first actor's methods as a legitimate design decision.

I'm sensing a disconnect between your beliefs and the justifications for holding those beliefs.    Space unicorns and Nutella sandwiches aside, would you settle for a situation where passing the actual Actor instead of its NQR may make sense?

[David_Staab]

Daklu wrote:

Space unicorns and Nutella sandwiches aside, would you settle for a situation where passing the actual Actor instead of its NQR may make sense?

I challenge you to come up with a suitable example where passing an AF actor object into another running AF actor object is a good idea.

[MattP]

I'd claim that it may make sense to transfer all data members from one actor to another (particularly if the actor doesn't carry much data), but that we should package it not as an actor but as a class, cluster, flattened string (pick your data structure) explicitly containing only that information that we intend to transfer. 

If later in development we add additional private data to the actor, I might not want that sent over to the other actor.  Explicitly choosing only the specific data members I want to transfer (even if they happen to be the full set of data at one point in time) reduces my maintenance load.

[Daklu]

"Good idea," or "acceptable idea given the immediate business constraints?"

[David_Staab]

Matt,

David Staab wrote:

If you want to share information about an actor with another actor, bundle that information in to a type of its own (a class or cluster) and insert that.

We're singing the same tune.

[tst]

David Staab wrote:

We're singing the same tune.

As am I (and I'm assuming Daklu agrees). I'm not saying that this is a good design or even that I *would* do such a thing. I'm saying that under specific circumstances I *might* choose such a solution if I felt that the various factors were balanced in its favor, just like I would with any other solution. I've consciously decided to write bad code in the past after weighing in factors and I will probably do so again. If you can't say the same then I salute your purity.