Nested In Place Structure Chain

[FlamingYawn]

I love the In Place Structure.  But when I use it to access the bottom level data of a fairly nested data structure, nesting five In Place Structures seems like too much work.

 It would be great if one In Place Structure could be used to do the work that these five are doing.  I'm sure there's much better ways of doing this, but it could look something like this.

I may be way out on a limb here; would this be useful to anyone else?

[AristosQueue (NI)]

I like it. I flagged this idea to make sure the developers who work on that feature see it.

[JackDunaway]

I like it too, but cannot visualize an implementation that won't look like Frankenstein's monster.

Here's a variation that's visually cleaner, but it looks strange, more like a Flat Sequence. (I would lean toward horizontal data indexing, but the disadvantage of course is length...) I don't like my rendition very much, but can someone come up with another variation?

[JackDunaway]

This feels a little better:

[jlokanis]

This seems like a similar problem caused by the same issues discussed in this idea.  Perhaps there is a new universal paradigm that can be created for directly accessing elements deep within a nested cluster.

Message Edited by jlokanis on 03-19-2010 12:22 PM

[AristosQueue (NI)]

Of course, there's another answer... instead of fixing the Inplace Element Structure, perhaps we should consider that the icky feeling we get when we use these deeply nested structures is a feeling we should listen to and stop doing it. Perhaps this should be a bright red flag that we're actually architecting our data and functions incorrectly if we *ever* have to do these deep accesses. This "deep accesses indicate a problem" is something that I read about in various data structure design papers: when any single function has to drill deeply into a data structure, the architecture is probably broken.

Let's look at this example... what is the name of the VI that is doing this operation? Probably something like "Pin Data.vi"... but to accurately name it, we'd probably be calling it, "Pin Data For J-th Signal Of I-th Cell.vi" Why does this subVI even exist? What is the need to expose such a deep level function to high level callers? What is the reason for making this function call? Can we rewrite this as an entirely different operation that doesn't tie ourselves to such a particular data structure? Should this be a string of subVIs where "CellArray.lvclass:Modify Ith Cell.vi" calls "Cell.lvclass:Modify Jth Signal.vi" calls "Signal.lvclass: Pin Data.vi"? What nightmares will we encounter five years from now when we try to refactor this code to change out the data structure?

These are questions worth answering. So while I still kudos the idea (because I always like the syntax of the language to be cleaner and because sometimes these deep accesses are the way to go), perhaps having some pain is good because it makes us think, "Should I really be doing this?"

Just a thought...

Message Edited by Aristos Queue on 03-22-2010 04:41 PM

[Marc Blumentritt]

This one is really usefull, if you use an array of waveforms and want to change t0 or values or anything of the waveforms...

[Intaris]

@Aristos

 Sometimes our hands are simply tied regarding data structures and dynamic re-ordering is expensive.

@ all

I would still prefer a universal "deep access" (Cool term AQ) to cluster information rather than making a single exception for this structure.

[TCPlomp]

Isn't that what they call a map inside 'text' languages?

Ton

[JackDunaway]

AQ - psuedo_kudos for the code smell guidance. (You're describing a "Bloater" according to the Code Smell Taxonomy).

[Brad_Hughes]

I find myself having to nest in place element structures because the lack of reference classes in LVOOP.  I use a DVR to implement a by-reference class.  Then you have at least one cluster to unbundle/bundle to get useful data and do something with it.  I'd love to see something like this happen.