Leaderboard

This was a post-signature, but I moved it up to the top because I felt my tone could be taken as dismissing your idea out of hand when, really, I was just trying to do a brain dump of the analysis I had already done on it years ago. If you think there's some direction to go with this, I'm definitely open to making the overall system for defining classes be more graphical, but using a VI to do it doesn't seem like the right way to go. (PS: I'm not just rejecting your idea on the fly... it's one of the diagrams I had drawn up in brainstorming while working on classes 8 years ago. I worked on it because something like that *is* how poly VIs are defined -- they have a block diagram, and floating on that block diagram are nodes of all the instance VIs. The actual block diagram is hidden behind the dialog because it turned out that you needed more control than just "this is the set of instance VIs". Tried something similar with LV classes at one point. Really, it is the same as what you're asking for except that we put a different interface on the definition and changed the save format to be human readable instead of XML.) You're confusing syntax with semantics. There's no C syntax for declaring a class -- C++ had to introduce new syntax. Likewise, there's no nodes you could drop on a diagram to define a class. We were going to have to put a new file framework together. We chose to save it as XML instead of binary, but we could have used binary, like VIs do. A VI is a function. A class is a set of functions. A higher order construct -- like the higher order keywords in C++ -- had to be introduced. We do use the syntax of the existing language for defining the data contents and the methods of the class. The class file is nothing more than the braces around the methods in C++. BUT, your point is that we could have introduced a new type of VI to do that, right? Let's consider where that rabbit hole leads... Problem is, that's a valid VI, not a class. And, really, it is *exactly* equivalent to the private data control VI that you do create -- only in yours, you have that extra useless front panel. You brag about not having a conpane, but you generate a whole extra window! :-) Which is actually where I was at one point, until I picked the whole thing up and moved it to the panel and eliminated the block diagram -- thus the private data control. Next, a block diagram isn't declarative -- it is execution semantics. In your later images, you are littering your diagrams with executable code as a way of declaring types. Although useful for on the fly type instantiation (a feature that would well be worth having in some really advanced use cases, and something we've discussed in R&D), it is wholly useless for defining a static type definition... you don't know when to execute these diagrams. See, the types have to exist *before the program is even loaded* because LabVIEW has data values for controls *immediately*. The dependency ordering is invisible. An execution syntax really isn't appropriate for a declarative semantics. Finally, there's no way to distinguish these diagrams from regular diagrams, where a programmer might have mixed in any number of runtime behaviors. Those declarations of functions that you've written? They look to me like function calls. What stops you from forking that LV class wire? why do you even have to wire the LV class wire? It's a sloppy syntax -- some methods do not have a class in. Some do not have a class out. Some do not have either. Some are global VIs and some are control VIs. SO... rather than wiring them together, take away the requirement to actually wire those nodes together -- you end up with a bunch of floating VI declarations and a cluster constant. Now, arrange them in a column. Now turn on labels. Now hide icons. You know what you get? The project tree. Yep. Exactly. You are asking for New >> Class VI. That ends up being pretty much the equivalent of New >> Class as it stands today. The project tree offers a more compact layout than a diagram and allows for folder organization. It also allows for New >> VI From Template so that new VIs are created already knowing what class they'll be a member of and thus can populate their controls/indicators. With a plain Class VI, you'd still be introducing some sort of gesture exactly equivalent to the project gesture for creating a new member VI. In the end, the question of what is "syntax" in a graphical language turns out to be rather more amorphous than most are comfortable with -- the final save format of the files is nearly irrelevant, which is the entirety of syntax for text programming languages. And, honestly, I think the project tree would be a better environment for defining PolyVIs if we were creating them from scratch today. So, for me, the lesson ends up going the other way. :-)