Does implied creation of a class also create state for internal processes?

[tobyk]

ClassInitialisingNestedProcessesBehaviour.vl (17.9 KB)

On 2022.5.0-310

This is one of those things that may have always been true but I just never noticed it before.

Is this correct behaviour that if you implicitly create a class (eg by just running a ‘set property’ method with no explicit create), that it won’t create state for internal stateful processes and they will give null object errors?

[tobyk]

This is something that came up for me when I built a manual deserialiser. I wanted to make essentially an alternate create operation for some classes.

In this case because deserialising is like ‘load game’, and different initialisation happen at ‘load game’ than at ‘new game’.

[gregsn]

Do not use this way of expression! It leads to patches that are less readable and also not really future proof.

I am not sure where you picked up the term “implied creation”, it for sure sounds legit :)

But tbh we currently only create an object for you in order to don’t interrupt you while patching. Here is our train of thought: Users don’t like pink nodes. We figured that out early on. Ok, we create an object for you so that you can just continue patching.

• no pink node
• no unused node
  while patching upwards.

But the final patch should clarify where an the object is coming from.

In the longterm future also expect the behavior to change. We will probably at some point switch to a flow analysis and instead of calling methods on a default instance - which is a bit random, we’ll grey them out as long as no object flows into the state input pin… (our thinking: no execution also means no pink node) So your example wouldn’t even execute. The “SetDamperTime” with unconnected input would be transparent.

[tobyk]

Ok thanks for the clarification.

‘Implied Creation’ for me is a very common pattern in VL.

For example I virtually never create a spread explicitly, I can use a splicer. Or an accumulator with add etc.

But If I should always use create that’s fine.

[tobyk]

Wait actually, now that I think about it this ‘implied creation’ is happening everywhere.

Here’s the ‘How to Manage Items in a dictionary’ helppatch

There’s no Create for that dictionary. And a dictionary is for sure an object. If it’s not ‘implied creation’ than how would you describe what’s happening?

Do you specifically mean don’t create Classes this way?

[gregsn]

I would say this help patch is showing an anti pattern. I’ll fix it.

Edit: For immutable collections it’s far less problematic than for any mutable types. That’s for sure.
Still preferring a patch style that explains where a particular object comes from, instead of out-of-air/implicitly/obviously-empty/magically.