Request: lose the "Caller-To-Actor" and "Actor-To-Caller" language

[AristosQueue (NI)]

JackDunaway wrote:

but should two methods exist to reduce ambiguity in the API?

How does this apply to the Launch Actor problem? We aren't trying to overload the functionality at all. We're simply trying to name the input.

tl;dr: I have a new option to lay on the table.

Actor has three functions:

     Read Self Enqueuer.vi -- returns the enqueuer that the actor uses to send messages to itself

     Read Caller Enqueuer.vi -- returns the enqueuer that the actor uses to send messages to its caller.

     Launch Actor.vi -- starts a different actor running

On that third function, there is an input. We could name it:

1. "Caller Enqueuer" because, in the context of the function, this is the queue that the nested actor should use for its Caller Enqueuer.
2. "Self Enqueuer" because, in the context of the majority of callers, this is the queue that needs to be passed in
3. "Actor-To-Caller Enqueuer" for the same reason as option 1 but being explicit about the directed nature of the queue
4. "Caller's Self Enqueuer" in an attempt to combine the reasoning of both 1 & 2

That third function also has an output. We could name it:

1. "Self Enqueuer" because, in the context of the function, that is the queue that the just-launched caller will use to talk to itself
2. "Actor Enqueuer" because, in the context of the caller, that is the queue that the caller uses to talk to the just-launched actor
3. "Caller-to-Actor Enqueuer" because it clearly identifies the direction of the queue communication.
4. "Actor's Self Enqueuer" in an attempt to unify 1 & 2

I don't like these new names as much as the existing names, but for the folks who see the names as limitations on the global usage instead of as specifications of its current use, this might satisfy their viewpoint without creating confusion in the names. Yes? No?

[D_Hooks]

My vote goes to "Caller's Enqueuer" for the input and "Actor's Enqueuer" for the output of Launch Actor.  You could drop the 's if it's easier.  Even though the current names are descriptive I find myself needing to think them through each time I see them.

Regarding the option #2's above, I think that naming a VI's inputs with regards to their most likely caller isn't really an intuitive or sustainable solution.  It would be pretty confusing if you started renaming "Error In" as "Error From Previous VI In Dataflow Sequence", and wouldn't really encapsulate all of the possible arrangements that the VI could be called from.

If you're using a VI called Launch Actor, and it passes out an enqueuer to the *new* actor, it seems like "Actor's Enqueuer" is by far the most reasonable naming.  This isn't making any assumptions about who will use the enqueuer once it comes out, or if the *new* actor was launched by another actor.  I don't think it requires many mental gymnastics to grasp that what is considered a "Self Enqueuer" internal to the actor is passed out as the "Actor's Enqueuer".

Naming the input "Caller's Enqueuer" does make the assumptions that the *new* actor is being launched by another actor who also has an enqueuer, and that you're adhering to a tree structure.  I think that this is reasonable considering that a tree is strongly promoted as the default structure for AF, and adding a "Launch Root Actor" without this input is also being considered.  Matching up the naming with the "Read Caller Enqueuer" VI seems important as well.

The "Enqueuer" nomenclature is a bit of a mouthful, but I see the reason for it.  You are not passing around actual queue references that can be enqueued and dequeued from, and I have no better name for it.

[AristosQueue (NI)]

D_Hooks wrote:

My vote goes to "Caller's Enqueuer" for the input and "Actor's Enqueuer" for the output of Launch Actor. 

As I said before, this suggestion (minus the apostrophe s) has already been tried in earlier drafts of the AF and was so confusing we changed to the current names. Even if the current names are confusing, they are measureably less confusing than the earlier ones. Since we have experimental evidence already known, I'm disinclined to consider this option.

[Daklu]

How does this apply to the Launch Actor problem? We aren't trying to overload the functionality at all. We're simply trying to name the input.

That was my initial reaction too, but then I realized he was bringing up a "tangential" topic.

tl;dr: I have a new option to lay on the table.

Thinking out loud... is the "self" terminology necessary?  It seems to add confusion instead of clarity as evidenced by "self enqueuer" being valid names for both the input and output terminal.  Once one understands that an enqueuer doesn't exist without being associated with an actor, "self enqueuer" becomes redundant.  It's sufficient to simply refer to it as an "enqueuer" and accept it is the enqueuer associated with that actor.

Following that line of thought, I'd favor "Caller Enqueuer" for the input terminal and "Actor Enqueuer" for the output terminal.  I'd also change "Read Self Enqueuer" to "Read Enqueuer" since the 'self' is implied.  (I actually prefer Get/Set over Read/Write for accessor methods, but that's not important here.)

[Daklu]

AristosQueue wrote:

As I said before, this suggestion (minus the apostrophe s) has already been tried in earlier drafts of the AF and was so confusing we changed to the current names.

Are you sure this is accurate?

Earlier in this thread you said "Receive Queue" and "Send Queue" had been tried, followed by "Caller's Send Queue" and "Actor's Send Queue," but "Caller's Enqueuer" and "Actor's Enqueuer" have NOT been tried.

[AristosQueue (NI)]

Daklu wrote:

is the "self" terminology necessary?

Yes, because it matches the name of the function in the caller that you use to get the correct queue. In other words, we need to somehow convey that it is incorrect within an actor to call "Read Caller Enqueuer.vi" and then wire that to the input of "Launch Actor.vi". Instead you need to call "Read Self Enqueuer.vi". If you drop the "self" then you're right back to the situation that caused all the confusion in the first place.

Daklu wrote:

Following that line of thought, I'd favor "Caller Enqueuer" for the input terminal and "Actor Enqueuer" for the output terminal.  I'd also change "Read Self Enqueuer" to "Read Enqueuer" since the 'self' is implied.  (I actually prefer Get/Set over Read/Write for accessor methods, but that's not important here.)

And we're back where we started. See my previous post to D_Hooks.

[AristosQueue (NI)]

Daklu wrote:

Are you sure this is accurate?

Earlier in this thread you said "Receive Queue" and "Send Queue" had been tried, followed by "Caller's Send Queue" and "Actor's Send Queue," but "Caller's Enqueuer" and "Actor's Enqueuer" have NOT been tried.

Technically correct. But the theme has been tried -- whatever you call the noun, whether it is "send queue" or "enqueuer" or just "queue", the adjective in front matched the wrong Read function.

[D_Hooks]

Aristos, I also read your previous statement of "we have NOT tried "Caller's Enqueuer" and "Actor's Enqueuer" -- maybe that would be better?" as saying that those naming options were on the table.

I agree with Daklu that the "Self" doesn't add a whole lot to the Launch Actor inputs IMO.  Though I would argue that keeping the title of Read Self Enqueuer makes sense since an actor could be handling several different enqueuers at any given point in time (self, caller, one or more callees).

Overall, it seems that a user of this framework needs to understand that the actors will be operating as part of a messaging hierarchy, with callers and callees.  If this were a class inheritance hierarchy it would be assumed that everyone has a parent, but for a given class the parent of your child is YOU, not your own parent.  The exact same thing applies to the messaging hierarchy with callers and callees, and if that concept doesn't make it through, the VI input naming won't be enough to save anyone.

[AristosQueue (NI)]

I meant it more as "perhaps better than previous, but still seems to run afoul of the same problem, which makes me loathe to go there unless someone is really sure we wouldn't be right back in the "this adjective+noun on this function matches this adjective+noun on this terminal so it must be the right thing to connect together"." I did say "I'm disinclined to consider this option", not that I wouldn't consider it. I'm trying to not reject it while at the same time highlighting just how bad I think it would be. If y'all stand by your positions, that may be where we end up anyway.

> Overall, it seems that a user of this framework needs to understand that the

> actors will be operating as part of a messaging hierarchy, with callers and callees.

Right, and generally we get that point across. But the recognition that "my queue" is only "my queue" to me and not to you and "caller's queue" *is* "my queue" is really hard to communicate.

> I agree with Daklu that the "Self" doesn't add a whole lot to the Launch Actor inputs IMO.

But does it detract in your opinion? That's in some ways the more important question. Because I think it adds a lot for people who are trying to figure out the right thing to connect to the terminal, even if it adds minimally, just having *something* breaking the direct word-for-word name matching.

[Daklu]

...the adjective in front matched the wrong Read function.

I wasn't quite following what you meant here and I'm not super familiar with the implementing AF apps in the first place, so I put together a simple little sample project.  Needless to say, I quickly discovered the conflict you're referring to. 

In fact, when I first wired it up I did exactly what you warned against--I used Read Caller Enqueuer to obtain the enqueuer to wire into Launch Actor.  Thinking about why I made that mistake, I don't believe changing terminology is enough.  I had a subconcious expectation that the "Actor-to-Caller Enqueuer" requirement for Launch Actor could be met by "Read Caller Enqueuer" because of the combination of the methods being in the same class and using similar terminology.  The context in which "Caller Enqueuer" was being used in those methods was obscured by too much similarity.

Perhaps providing more differentiation for Launch Actor (changing the banner, rearranging the pallete, and/or moving it to a different class) would help?  I typically put icons on my private, protected, and community methods to identify their scope; maybe something as simple as that would help emphasize the contextual difference?

Incidentally, I don't have any strong objections to "Caller's Self Enqueuer" and "Actor's Self Enqueuer."  I do think "self" terminology is redundant, overly verbose, and (incorrectly) implies the self enqueuer and caller enqueuer are equal in importantance, but these are relatively minor issues.