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

[fabric]

For the record:

I'd like to see them named "Actor's message queue" and "Caller's message queue"... Simple terms that anyone can understand.

At a pinch I'd settle for "... enqueuer", but it's just such an awkward word. Is it even a word? Google it, and all you get is a bunch of obscure programming references. IMO cumbersome explicitness loses out to simplicity here.

[CaseyLamers1]

I don't see a problem with self-enqueuer and caller-enqueuer.  I suppose truncating it to simply self-queue and caller-queue would work too.

I use a tree architecture but I do have some sharing of specific enqueuers (like an error logger).  When I share an enqueuer explicitly then it is stored in the private data of the class that uses it and it goes by name.  Otherwise I use loose coupling and my lower level components don't know who their caller is, just that they send certain messages to their caller.  Any higher level components that launch "nested" actors store the actor's enqueuer in their private data explicitly.  In this use case the existing names work fine because you either send messages to a enqueuer that you named and keep in your data, you send a message to yourself, or you send a message to your caller.

Casey

[AristosQueue (NI)]

kegghead wrote:

From a philosophical (that is almost irrelevant) standpoint I don't like the "Caller-To-Actor" nomenclature because nothing says that enqueuer has to be explicitly used by only the caller. Though I firmly believe a component should never expose it's actors' enqueuers directly to the outside world (because of the ability for a malicious or poorly designed message to swap out your actor at will, see @lava) the framework doesn't prevent as much, so I think it's presumptuous to assume that the enqueuer will only ever be used by the caller.

Wow. This post gives me a significant insight into one major difference between the thought process in my head vs. some of the objections to this name. Neither of us is wrong, but the viewpoint is very different.

From my view, just because the terminal on "Launch Actor" is named "actor-to-caller" does not imply *anything* about what that queue is used for elsewhere. It simply means "this input needs to be wired with whatever queue the actor should use to talk to the caller." The fact that that same queue is also the self queue in another context and is also shared through the actor tree has no bearing on the fact that at the moment Launch Actor is called, it is the queue that fulfills that terminal.

From your view, any terminal that the queue is wired to needs to be named something that does not restrict its usage. You appear to take more of a "this is part of its data type" approach -- i.e., if I wire it to something called "actor-to-caller", then that must be because it *is* an actor-to-caller.

I don't know how to reconcile these, but the insight is useful -- if we can see the distinction in view, we might be able to bridge it.

[AristosQueue (NI)]

Daklu wrote:

Currently the AF only supports a static message tree--once an actor has been launched there is no ability to change the actor-to-caller enqueuer.  If AQ decides to add a setter method and support dynamic message trees then "caller enqueuer" is less useful, since the actor that launches another actor may not be the actor that is currently managing it.

As of right now, I would say that kind of dynamic reparenting is not something I would support seeing. It violates too much of the structure of actors. Keep in mind -- my main goal with AF is to *simplify* the programming of these massive systems. The discovery of the caller invariant is crucial to the patterns we've enabled with the AF. If you start playing with that, you're now into some really nasty resource management territory. If a caller wants to hand its actor over to some other caller to manage -- something no one has yet requested to do -- AF at the moment would say the right way is to stop the actor, catch the Last Ack message, and then give that actor object (which is inside the Last Ack) to the new caller and have it call Launch Actor.

[AristosQueue (NI)]

CaseyLamers1 wrote:

I don't see a problem with self-enqueuer and caller-enqueuer.  I suppose truncating it to simply self-queue and caller-queue would work too.

There's a pretty major problem with these names.  It is the same problem you have with VIs calling subVIs. The input terminal of a subVI node is an "input". But when we look at the block diagram of the subVI, a control's FP terminal is an output terminal. So when I try to write scripting code, there's a constant back and forth between the same terminal being a "sink" in one context and a "source" in the other context.

Same problem here. Consider the input of Launch Actor.vi. The input queue is the one that the actor will use to talk to the caller. So I would assume you would call that the "caller queue". But suppose I am writing an Actor Core.vi override. I drop Launch Actor.vi. And then I use my own Read Caller Enqueuer.vi and wire that up. Oops. I've just wired entirely the wrong queue. A terminal named "caller enqueuer" needs to be wired with a value of "self enqueuer". And the output "self enqueuer" is not the same as my own self enqueuer.

If you flip the names around then the terminal names do not match the naming conventions.

[AristosQueue (NI)]

fabric wrote:

At a pinch I'd settle for "... enqueuer", but it's just such an awkward word. Is it even a word? Google it, and all you get is a bunch of obscure programming references. IMO cumbersome explicitness loses out to simplicity here.

Yes, it is a word, by virtue of the fact that English, by grace of God or sheer dumb luck, has the ability to coin words we have never used before as soon as we encounter a situation that requires them. This reference is not a queue reference. Queues both enqueue and dequeue. This is merely one-half. And classes are best named as nouns.

See my previous post for the problem with naming the terminals "Caller's message queue" and "actor's message queue".

[wirebirdlabs]

AristosQueue wrote:

kegghead wrote:

From a philosophical (that is almost irrelevant) standpoint I don't like the "Caller-To-Actor" nomenclature because nothing says that enqueuer has to be explicitly used by only the caller. Though I firmly believe a component should never expose it's actors' enqueuers directly to the outside world (because of the ability for a malicious or poorly designed message to swap out your actor at will, see @lava) the framework doesn't prevent as much, so I think it's presumptuous to assume that the enqueuer will only ever be used by the caller.

Wow. This post gives me a significant insight into one major difference between the thought process in my head vs. some of the objections to this name.... I don't know how to reconcile these, but the insight is useful -- if we can see the distinction in view, we might be able to bridge it.

Which is the significant insight: that any number of arbitrary actors could be aware of an Actor and write to its Enqueuer, or that messages to and units of work (jobs) performed by an Actor are one and the same in AF?

[AristosQueue (NI)]

Jack: Neither. The insight is that people consider the name of a terminal on one function to have implications for limiting the usage of the value passed into or out of that function when it is used on other functions.

[wirebirdlabs]

AristosQueue wrote:

Jack: Neither. The insight is that people consider the name of a terminal on one function to have implications for limiting the usage of the value passed into or out of that function when it is used on other functions.

Aha, that's another good tangential topic, since it directly relates to OO API design.

The two scenarios of calling that function you describe -- should it even be the same function if the ConPane names need to be different to better suit the calling context? Or, should we have two methods, one appropriately named for each calling context?

Sure, the work done by the method under the hood might be exactly the same (for now!), and one method could even be a wrapper for the other, but should two methods exist to reduce ambiguity in the API? (Not sure if this discussion is academic or practical, but I'm have current considerations along these lines, so it's a topic of interest)

For discussion, one notable API is the Variant Attributes API that ships with LabVIEW. The "Delete Attribute" method will delete a single attribute if it's explicitly wired, or delete all attributes if it's not wired (or empty). I think this is clearly a case where we need two methods, "Delete" and "DeleteAll" (at a minimum, to satisfy the Principle of Least Astonishment), because each behavior has a clear delineation. But where do we draw the line on "clear delineation" between two methods, and what is considered "overloading"?

[Daklu]

The two scenarios of calling that function you describe -- should it even be the same function if the ConPane names need to be different to better suit the calling context? Or, should we have two methods, one appropriately named for each calling context?

I prefer to give terminals names corresponding to the roles the inputs play in the context of the vi being called rather than trying to define what the inputs are.  As an API developer I only have the ability to define the data type of the input.  I can't dictate how the end user comes up with the inputs or what other roles those inputs might have in the overall application.  (Hence, "input/output" instead of "caller/callee.")

That means, in general, I favor multiple VIs with contextually good names versus a single VI with poor names.  However, if the connector panes of two VIs are identical then I'd go with a single VI and more generalized terminal names.  In the context of this discussion, I think having both "Launch Actor" and "Launch Root Actor" VIs is a good thing, since their conpanes are different.  But I wouldn't suggest having a "Launch Actor From Caller" with the terminal name Caller Enqueuer, and a separate "Launch Actor From Somewhere Else" with the terminal name Controller Enqueuer.  That's just confusing.

(In other words, don't create duplicate VIs just so you can rename the terminals for different contexts in which the VI might be used.  Instead, give the terminals names that make sense regardless of the context.)