[Proposal] Classes read and write fields on the fly, "through-pad"s get a warning in Records and Process Patches

[gregsn]

This is here to solve the quest #19. Let's assume we settled on being able to easily express execution order like via this proposal: #24 With that, we would assume to be able to express what is called when. It would be nice if this would be true for reading and writing fields as well.

For mutable datatypes (aka classes) it is crucial to be able to do this sooner or later. Especially when more and more patches make use of the This node, where calling an operation on our own instance may change the value of that field.

• Pure Setters: So let's just say that the compiler looks at the data dependency graph and figures out that it would be ok to write the field after some upstream nodes got called. However, it still can write the field right away or postpone it a bit. I'd argue that if there is no visual constraint, then there is no compiler constraint. The compiler would be able to write the field sooner or later.

• Through-Pad: There is a data dependency. You can see how the field gets written and the value then flows downwards. So everything downstream of course should get executed after the field got written. Just as the patch suggests visually.

• Pure Getters: The only guarantee here is that they get executed before whatever follows downstream. But whether they get called right at the beginning isn't really defined.

If we now are unhappy as a user, we can always use Horizontal Lines as Execution Helpers in order to execute a getter or setter at the right moment. We even could allow reading and writing fields several times. Again: this only applies to classes.

For Records we could try to make this work to some extend. And it does work to create in-between immutable snapshots, where just one field got changed, feed that to the MyOtherOperation, but you can trick yourself so easily, and what does This again mean for records, isn't it the incoming unmodified state? I'd rather keep the old idea of "split the State-Input in the beginning and join the State-Output in order to create a new snapshot at the end". And only put warnings on pads

• that visually wrongly suggest, that they get read later than right in the beginning or
• that visually wrongly suggest, that they get written earlier than at the very end of the operation (they still get written at eh very end).

To be discussed details: Option A of this proposal: We could make the Getters execute as early as possible, the setters as late as possible. Option B of this proposal: We could make the Getters execute as early as possible, the setters as early as possible. Option 0: undefined

Option A is the most conservative change since up to now you only have super early getters and super late setters. So I am in favor of that.

[gregsn]

Speaking of conservative change: We should make sure that we only add functionality and don't change semantics of everything unrelated.

For example we still want the switchable Process patches, that get initialized as mutable or immutable depending on where they get used. An LFO in a Record-Particle shall still work the same way as before.

So all I am saying is: Just change the experssivness inside a class patch, and change the target code of the class patch, don't change Records and Process patches and the way they get compiled.

[azeno]

Option A is now implemented in 2021.4 - we're missing the warning still on the "through-pad".

[gregsn]

Ah, and there is the idea to let the user read and write a pad several times. But yeah, that's a feature that will probably be postponed until after we better support defining the execution order. So close this and add another shorter proposal?

[gregsn]

Option A is now implemented in 2021.4 - we're missing the warning still on the "through-pad".

Warning got added for through pads in Records. https://github.com/devvvvs/vvvv/commit/66e90cebdbf475f2feef41ef6a51aac15a5134a3