Potential ambiguities when using the ‘Apply’ pin

I’m not entirely sure I fully understand the problem I’m trying to describe. I’ve come across it many times, but I’ve never quite been able to figure out whether I’m doing something wrong and it’s actually by design, or whether it’s actually an oversight and worth looking into. It’s frustrated me on several occasions in different contexts – perhaps it’s happened to anyone else?

To summarise, the automatic appearance and disappearance of the ‘Apply’ pin follows a somewhat mysterious logic. I partly understand it, but often I don’t.

Let me explain: I create something in a class or a process and start using it. Great, I’ve got Apply! I use it to call certain operations on the class. And then I decide I need to pass some data to that operation, and voila, the apply pin disappears! And now I have to wrap it in an if statement (which looks a bit ugly). What’s more, it happens so counterintuitively and randomly that it almost always feels like some sort of bug.

I’ve wanted to write about this for a while.

I’ll try to come up with some more examples, or we could discuss them and come up with some together.

This actually quite simple explainable:

When you have only input connection you can trigger this.SetValue(...) but when you have the output pin, it’s already a different story, e.g. something is requesting for an value. for instance if you place that in method in Update inside update it would look something like:

void Updatate() {
   _myLovelyClassIntance.SetValue(x, out var value)  // value is requested
}

I can’t find an clear code sample of this, but in case you have only an set you may set or may not set, but in case of get the system would call whole operation if get is requested.

Not sure if this clear enough explanation but point is that: if you place output on same operation it would be called when output requested and not when set applied, so it Applies when getter is called, not when you want to call set.

Your operation in case of get have to provide result independently of you want to call it or not, since otherwise you get some null reference exception (same as it would happen if you call class operation without instance of class).

That’s why in vvvv getter are actually significantly more complicated then setters if you dig that in C#…