LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
chris_d754

Inner Classes

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined. 

I would love to see inner classes. Inner classes can allow for more elegant code. Sometimes you run into situations where two classes are closely tied together that they appear to be one class, but not quite the same. Inner classes can handle this situation very smoothly. Thoughts and other considerations are welcome.  I didn't see it posted and have a few instances where an inner class would be beneficial.  I'm not sure how hard it would be to implement such as idea, but definitely think it should be considered.

 

Thanks

Chris

5 Comments
AristosQueue (NI)
NI Employee (retired)

It has been considered. And rejected. Let me explain why then you can put together a counterargument and we'll see how the kudos go.

 

We talked about inner classes early on in LV OO development. I floated them in front of multiple LV users, trying to explain the concept, including many who knew OO from other environments. Too many users couldn't keep straight the idea of the class containing an inner class and the private data control containing an instance of the class. The vocabulary was a problem, and it seemed the graphical nature of LV made the problem worse than in other languages. Look at how many people aren't careful when they use the term "object" vs the term "class". Having inner classes in the mix makes that confusion worse. It was really a struggle for enough users that I felt we could keep that feature out of the language.

 

I looked at large programs in other programming languages and saw that inner classes were used relatively rarely.

 

If you put a library wrapper around your two classes and make one of them private then you achieve the same goal.

 

So, in short, we have a substitute that does the same thing, they confuse people, and they're rarely used in languages that do have them. So they don't exist in LabVIEW.

 

Bad idea or good idea?

AristosQueue (NI)
NI Employee (retired)

PS: You're also, I think, the first person to ask for them in almost a decade. I don't remember getting any questions about this since the first couple weeks of the release when people were checking C++ feature lists against LV OO feature lists. That gives me a clue that they aren't in high demand.

chris_d754
Member

Thanks AQ for you response. I agree completely that Inner Classes are a niche use case and an advances OO feature taht few care to learn and/or use. I don't think that this fact should preclude it from being an available and valuable feature of LabVIEW. Having said that, that fact may preclude it from using valuable man-hours to develop such a concept. I'm sure you have much bigger fish to fry. I do think it is worth people looking at here and discussing the topic, although no one else seems to be as interested as me :).  I do like your workaround, and may use this in the future.

AristosQueue (NI)
NI Employee (retired)

> I don't think that this fact should preclude it from being an available and valuable feature of LabVIEW.

 

Oh, I do. Every thing that we add to the language is a thing that *someone might use*. I can't tell you how many new developers have broken on teams in C++ having to understand some niche, rarely used language feature.

 

There is always a balance to be struck between power and readability, and if a feature can be left out because, with the same effort, it can be achieved through existing means, then I believe it should be left out.

 

I hope the library wrapper works for you. It's more than a workaround -- it's the intended solution for this scoping problem! 🙂

Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.