New node for In Place Element Structure for converting a class into a child class and back

[Marc Blumentritt]

Hi,

the idea subject says it all. I think this is usefull for multi-level data types with data placed into the parent and its child class (and in the child of the child class ...). To transport the data, you use the parent class. If you want to modify the data inside of a child class, you program a corresponding dynamic dispatch VI or you have to convert the parent class to its child class, modify the data, and convert back to parent. The In Place Element Structure would be nice for the second method.

Regards,

Marc

[tst]

You don't HAVE to convert back to the parent. The parent VIs can accept a child and if needed, the child will be automatically upcast, so basically you're saving one node (which isn't necessarily bad, but is not as needed).

[Marc Blumentritt]

Yes, it can automatically upcast, but there is a red point, if I connect a child to a parent and I d'ont like red points 😉

To be serious, I have learned to prevent as many conversion points as possible, because the code looks nicer AND in many cases does run a tiny bit faster. What's with this case? Should we use "convert to more generic class" or just directly connect a child to it's parent?

[tst]

> Should we use "convert to more generic class" or just directly connect a child to it's parent?

Just connect it directly. As far as I know, there's no copy made in this case, so you don't suffer a penalty for that.

[AristosQueue (NI)]

> What's with this case? Should we use "convert to more generic class" or just directly connect a child to it's parent?

The "To More Generic" node is a true no-op for LV classes. When we compile the diagram, that node disappears entirely (although if you wire the center terminal from somewhere other than a constant, it will still maintain dataflow ordering for execution).

Coercion dots have long been argued to need two colors... red for places where LV is really changing bits (ie. wiring an int32 to a double) and some other color for places where LV is just reinterpreting the bits without making any copies (ie wiring an int32 to a uint32, or a child class to a parent class). The latter have no performance hit, they're merely feedback to the programmer. Unfortunately, people have a hard enough time seeing the red dots. All other colors are even harder to see, and there's not enough space to decorate with a pattern change or anything. As a result of the physical limitations, all coercion dots look the same.

Somewhere in the idea exchange is an idea for changing the coercion dots, but the thread kind of died because no one could come up with another style that was actually readable on the diagram. If you have ideas, search out that thread and add comments.

[Marc Blumentritt]

I remember know the thread, too. I will look into it.

But back to my idea: while the benefit is not as big as I thought, is there any good reason against it? I like the In Place Element Structure a lot, since the code does look much cleaner. So why not adding more possibilitys to use it? While we are at it, you could do the same with references. And what about datastream to value and back to datastream?

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.