Set index inputs on LVOOP array element accessors to Required

[tst]

I almost never use accessors for array elements, but recently I did and I found something I didn't expect:

The index inputs on the accessor VIs are set to recommended, so you might not notice that you didn't wire them in. I expected them to be required.

I checked and found out that this is a design decision - it was done that way because that's how the Index Array and Replace Array Subset primitives behave - they don't require you to wire in an index.

However, the argument could be made that those primitives behave that way because they can be expanded (although they apparently behaved the same even before the expansion feature was added).

In addition, the In Place Element Structure does have the index input set as required, so LV already has a counter-example built-in.

Since it's basically a choice between two valid scenarios, NI needs user input to decide, so that's where your votes come in.

Personally, I think it's less important what other features in LV do and more important to allow people to safely and conveniently use my classes. I would expect that in most cases I would want the inputs to be required, so that's the idea here - Change the index inputs on LVOOP array element accessors to be required by default:

[SteveChandler]

Kudos. You probably almost always want to make sure it is wired. For the times when you want to allow it to be unwired it is easy to change it to recommended.

[AristosQueue (NI)]

Do you almost always want to make sure it is wired? I really don't know how to answer that question. Robbie and I made the call to make this like the Array Index primitive, which does not require the input. There are many times when I use that prim with its input unwired, so I've definitely used that feature.

It's easy enough for you to flip in the templates on your copy of LV. I'm honestly not sure which way is the best choice.

[Darin.K]

I did a quick survey of the Array functions, and for some reason the Context Help claims the index input is required for Index Array. I like consistency, and recommended seems right (just barely). I do have a hard time ever disagreeing with tst though....

[tst]

AQ, recommended is perfectly fine for Index Array. I wouldn't suggest changing that, and the IPE structure does actually annoy me when it requires the index, because I sometimes (don't know how often) do want it to behave the same as Index Array and Replace Array Subset.

That said, they generally operate on raw arrays. While it's true that the accessor VIs technically do that as well, I feel that it's usually a more specialized case of array access, where the user will usually want to use a specific index.

Additionally, this is particularly annoying because there's a dissonance between this behavior and the behavior I rely on of LV automatically setting inputs on subVIs to required. This is actually what bit me in this case, because I was subconsciously expecting the inputs to be required, just like the inputs on any other VI.

[SteveChandler]

@AQ Do you almost always want to make sure it is wired? I really don't know how to answer that question.

I have written nearly three array accessors and want the index wired in 100% of them. But in all seriousness it seems odd to have anything unconnected in an object accessor or method. That is what I meant by almost always wanting inputs wired.

Thinking about how I have used the index prim, there does seem to be many cases where I want the first element. I am glad that I don't have to wire the index for that. So now I am rethinking my support of this.

[AristosQueue (NI)]

> But in all seriousness it seems odd to have anything unconnected in an object accessor or method.

Oh, I agree it is less common -- I am the one who put in the option into Tools >> Options for new terminals to be Required by default. 🙂 But it does need to be judged on a case-by-case basis, and I have plenty of code where I have a recommended terminal or two. I have a Priority Queue implementation where I made the Priority recommended because it was relatively rare for the high or low priority to be needed. The "Ignore Previous" input on the Notifier primitives is another instance.

> I have written nearly three array accessors and want the index wired in 100% of them. But in all

> seriousness it seems odd to have anything unconnected in an object accessor or method. That is

> what I meant by almost always wanting inputs wired.

The couple times I have used this, I was trying to wrap an array with specialized behavior -- like any time you added elements, they were always sorted into position instead of just appended. In those cases, I wanted it to behave just like a regular array in all other cases for people using the API.

On the flip side, if I were building something more akin to a Map behavior, I'd want that to be required.

On the flip flip side, if you want it recommended and it is required, you'll quickly be annoyed by the requirement and go make it recommended. If you want it required and it is recommended, you may just forget to wire it a few times before you realize the problem. So maybe it should start as required.

I can keep going back and forth... keep debating ... if the idea racks up enough kudos, it's easy enough to make this change.

[drjdpowell]

> On the flip flip side, if you want it recommended and it is required, you'll quickly be annoyed by the requirement and go make it recommended.

> If you want it required and it is recommended, you may just forget to wire it a few times before you realize the problem.

> So maybe it should start as required.

This tips the balance for me.  Start as Required.

[crelf]

AQ Wrote:

"On the flip flip side, if you want it recommended and it is required, you'll quickly be annoyed by the requirement and go make it recommended. If you want it required and it is recommended, you may just forget to wire it a few times before you realize the problem. So maybe it should start as required."

Yeah, I'm with drjdpowell - a lot of my code is used by other people (hey, isn't that one of the awesome things that encapsulation bring us? 🙂 ), so I can see some of them getting annoyed with that.  I personally don't care whether it's required or recommended by default, but I can see the above use case happening.  I vote for required by default, but only by the slimmest of margins, and only if it's a really quick fix.

[tst]

---

crelf wrote:

a lot of my code is used by other people...so I can see some of them getting annoyed with that. 

---

This has nothing to do with people using your code. Each API needs to make the individual decision for whether or not each specific input needs to be required or recommended.

The point of this idea is for the developer of the class - my environment is set to have controls default to required, so I expect these controls to honor that setting (although I specifically didn't ask for the controls to follow this setting because that would be more work than changing the template, which is what my idea asks for). Making the control required makes you more likely to notice this if you want to change it back. I prefer safety.

[Neil.Pate]

I say make it required.

The accessor node is not a LabVIEW primitive node, it is user code, so it does not have to behave stictly like the index arry primitive?