Make FlatSequence part of MultiFrameStructure class

[jacemdom]

The FlatSequence structure was not classified as a MultiFrameStructure but was put in a class of its own. This causes the creation of "exception code" that would not be necessary if the FlatSequence was a MultiFrameStructure and could be processed with generic code. Issue was discussed here, it was decided that the investment to fix this was to high. I believe that the longer NI waits to fix it the higher the cost will be and the higher the cost associated with treating the exceptions cases will have become. I also believe that someday this will actually prevent NI to create more efficient code, i know it has prevented me to do so.

[AristosQueue (NI)]

Yes, but no.  🙂

This request is a perfect example of invalid inheritance under the "identity, state, behavior" rubric.

The flat sequence structure CANNOT be a multiframe structure because it doesn't maintain the same state as the ancestor class. Namely, it does not define a "currently visible frame", nor is its bounds computed the same way. As far as behavior, its execution behavior is not the same (outputs from the first frame allow downstream nodes to fire before outputs from the last frame are even computed, meaning the Flat Sequence as a whole isn't even a coherent node!). Only "identity" passes, and all three have to pass for there to be inheritance.

I agree it would be lovely if there could be a unified hiearchy for the flat sequence with everything else, but it fails every software engineering test you can throw at it for acceptable forms of inheritance. We might be able to create some sort of side-band interface for both types to inherit, but even that would be hard to define.

This is not broken so it cannot be fixed. The flaw is in the logical nature of inheritance, not in the nature of NI's implementation thereof.

[jacemdom]

Could "currently visible frame" become "currently visible frameS" and could outputs from all frames be synchronized except internal ones that could be treated like "Sequence locals" in stacked sequences?

[AristosQueue (NI)]

Jacemdom: There are lots of things that could be done to design a completely different feature and a completely different class hierarchy. 🙂 Your particular change would break binary compatibility with all the existing scripting code. Not generally an option we like to exercise.

There are other issues that would still remain even if we made your change. Fundamentally, the flat sequence is not a node... it is a layout manager for nodes.

We could have done something like remove the flat sequence from the ownership hierarchy entirely, and done something where a sequence structure has a reference to its "flat manager" or something like that, and then scripting would refer to the sequence structures directly, and operations on the sequence structure would sometimes fail when its "flat manager" didn't allow them. In some ways that would be a better design, in some ways a worse design.

But the point is, given the current embodiment of what the flat sequence is, we're stuck with the inheritance hieararcy that implies.

[jacemdom]

I was expecting something in those lines but i had to try!

Thanks for the explanations.

[Darren]

I understand all of AristosQueue's points above, but as a hardcore scripting developer for the past 15 years, the FlatSequence anomaly in the VI Server class hierarchy has caused me endless trouble. Maybe inheriting from MultiFrameStructure isn't the answer, but the current implementation is extremely difficult to work with, and I'd like to see NI address it in some way in a future implementation of the VI Server class hierarchy. Kudos.

[jacemdom]

---

@Darren wrote:

but as a hardcore scripting developer for the past 15 years, the FlatSequence anomaly in the VI Server class hierarchy has caused me endless trouble

---

Makes me think of the first time i tried to map wire paths through a flatSequence 

I believed the important word here is "caused" past tense! Would be nice though if others wouldn't have to go through this but then again this could be viewed as a rite of passage!

[Darren]

National Instruments will not be implementing this idea. There is no further feature development planned for modifying the existing VI Server scripting hierarchy.

[wiebe@CARYA]

Is there a reason a FSF isn't a node?

It's weird that getting all nodes from the diagram does return the FSF, although they are not nodes. Spooky.

[Darren]

That's not what I'm seeing. In LabVIEW 2019, if I traverse a block diagram (with Traverse for GObjects.vi) for the 'Node' class, Flat Sequence Structures are not returned. Similarly, if I read the 'Nodes[]' property of the Block Diagram class, Flat Sequence Structures are not returned there either.

[wiebe@CARYA]

Sorry about that.

It's the Diagram FiringOrder property that returns [nodes], including FSFs.

Tested in LV13 and LV18.