Why are LVOOP classes not specified in G?

[jzoller]

I could use some help from the experts in understanding this.

 

When defining classes is most other languages, you simply use the language itself to specify class behavior.  In LV, there's this meta-language of project and dialog, with underlying xml, before you can get to an actual instance.  It's... aggravating.

 

The G language is certainly capable of representing the concepts in a class definition.  Why isn't there a "class definition" VI?

[drjdpowell]

How do you distinguish language from meta-language if both are text?

[jzoller]

Syntactic distance

 

But this avoid the question.  Given multiple representations of the the same information, why not use the more familiar one?

[JamesMc86]

I'm intrigued, how do you see G representing classes?

For me as a data flow language it isn't so good as a structure definition. We use .ctl for data structures which is used for classes and obviously VIs for methods. The XML part leverages the existing (although not by much) library system.

Having said that I have heard criticism for OO that it takes too much away from the diagram and I think more that can be kept as G the better, or maybe some similar graphical representation.

[JackDunaway]

+1 for a good question.

 

 

In LV, there's this meta-language of project and dialog, with underlying xml, before you can get to an actual instance.  It's... aggravating.

 

 

Playing devil's advocate, I appreciate LVClass, LVLib, and LVProj underlying representations as XML -- source code control infrastructure (including diff/merge) generally just work way better with text formats. (It would be super slick if all LV filetypes likewise were represented as XML, or JSON, or... not binary)

 

In terms of editing the class definition on a diagram, can you provide some examples? Sounds neat.

[Darin]

C++ was not born by writing a new compiler, instead it was born by writing a pre-processor which converted C++ to C so the existing C compiler could handle it.  Certain elements of the syntax were clearly influenced by making the pre-processing easier and not always by what made the most sense.  How would you implement OOP in a text language and how would you implement OOP in C are two different questions.

 

Likewise, LVOOP was not designed from the ground up, but rather cobbled together leveraging existing LV elements as much as possible.  Once again there are two questions.  The question asked by the OP, How would you implement OOP in a graphical way.  And the question NI had to answer, How can you take the absolute minimal set of OOP principles and implement that in existing LV technology.

 

My own opinion is that the implementation of OOP looks poor in the context of how would you implement it in a graphical language, but quite reasonable in the context of mapping OOP to existing LV capabilities.

 

Introducing OOP to LV programmers usually leads to much happiness.  Introducing LV to OOP programmers usually leads to a fair amount of frustration.

[JamesMc86]

+1 for a good question.

 

Playing devil's advocate, I appreciate LVClass, LVLib, and LVProj underlying representations as XML -- source code control infrastructure (including diff/merge) generally just work way better with text

IF the merge didn't corrupt them! :-P

Perhaps if you could have the class hierarchy view with some fast edit ability. As Darin said maybe because I started with LV I don't fully follow how you can get to code faster though.

[jzoller]

Thanks for the replies.  My boss wants something done so we can make money... I'll post a bit more this evening.

[jzoller]

JackDunaway, I would love an intermediate, user-land language for LV.  DFIR's fun to look at, but it's really a compiler toy.  (If I recall correctly, WriteDFIRDot=true and graphviz can make for fun afternoon of spelunking.)

So, here are some ideas.  Would it work?  If I knew, I wouldn't have asked the question .

In addition to defining LV classes in LV, there are two other goals.  First, the entire system of creating and managing classes should be simpler than the existing system.  Second, the system should be more in line with the existing LV paradigm.  (Python uses the term "Pythonic", but there's nothing equivalent in LV that doesn't sound graceless.  L-Vesque?)

The whole notion hinges on a special type of VI for class definition.  It acts like a .ctl with a block diagram.  That is, it's not *run*, rather, it's compiled to a static form when it's saved.  Unfortunately, it might look like a constructor, but it's actually equivalent to a "class" declaration in other languages.

For behavior in the IDE, though, the class definition VI is a lot like any other VI.  It uses wiring to define its logic.  It's saved/moved/deleted like any other VI. It only has a single entry in the project, and carries most of its information in the VI itself.  The interpreter provides a broken run arrow when the definition is not valid.  When the definition VI is dropped on a normal VI, it gives an instance of the class.

The simplest possible class is:

<

Drop and populate cluster, save and you're done.  There's no conn pane, either.  It's not going to get much simpler than that... but it's not very much like LV.  No output.  No wires for logic.  Not much to work with.

So how about we change it to something like this:
 

There's data, a node to work with, and an actual output.  Still pretty simple, and it looks a lot like LV.  It gives something to hang onto:
 

I've tossed in a probe prototype, because it's trivial to do within the editor.

A surprising number of class properties (locked, protected, icon, documentation, etc) can be handled in the same way every other VI handles them.  Others, like wire type, friends and items are going to need to use property nodes.
 

I think the idea falls down a bit here, because LV's expression through property nodes is rather inefficient.  Particularly if you end up wandering down a hierarchy (see: .NET, scripting).

The methods that belong to the class need to be specified.  How about dropping them right on the diagram, like any other subVI?
 

There are a lot of questions to ask and corners to fill.  How do you view the class hierarchy?  How do you handle access levels on methods?  How do you handle property node access to private data?  And of course, there are certainly things I'm not seeing.

 

Joe Z.

[Aristos Queue]

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.)

 

I could use some help from the experts in understanding this.
 
When defining classes is most other languages, you simply use the language itself to specify class behavior.  In LV, there's this meta-language of project and dialog, with underlying xml, before you can get to an actual instance.  It's... aggravating.
 
The G language is certainly capable of representing the concepts in a class definition.  Why isn't there a "class definition" VI?

 
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...
 

The simplest possible class is:
<<< picture>>>
Drop and populate cluster, save and you're done.  There's no conn pane, either.  It's not going to get much simpler than that... but it's not very much like LV.  No output.  No wires for logic.  Not much to work with.

 
 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. :-)

[ShaunR]

And, honestly, I think the project tree would be a better environment for defining PolyVIs

+1000.

[jzoller]

Thanks for the feedback AQ.  The detail is appreciated.  And I understand what you're saying.

 

There's a big distance, though, between saying "This shouldn't be implemented in a VI" and "The project system is the best of all worlds!".  Project comes with it's own set of quirks (And crashes.  Ah, manually repairing XML).  More to the point, project fragments the views and manipulation of classes... some over here in this New wizard, some in this VI, some in this .ctl, a bit in this hierarchy dialog, and a whole bunch hidden under this oddly-inconveniently-placed-and-totally-unremarkable-yet-massively-important Properties menu item.  And basic things, like accessing base class data in an inherited class, are going to take me nineteen steps and eight wizards and six saves to string together.

 

The project system is too much overhead.  So, VI's aren't a better way... is there one?

 

(Now, if you told me "It's project, or implement an entirely new mechanism and we're a year behind and sales said if we didn't have it done by Saturday our defense contracts were all leaving...", THAT I would understand.)

 

 

 

 

[Daklu]

(If I recall correctly, WriteDFIRDot=true and graphviz can make for fun afternoon of spelunking.)

 

Can you elaborate?  I asked someone at NI (who doesn't participate in the forums) about getting DFIR representations of my code but was stonewalled.

[Aristos Queue]

By the way... the data dump I did earlier missed one point.

 

Although I don't really like a single diagram for defining a class, a diagram for defining a class *hierarchy* is something I have a keen interest in. It would not look like an execution block diagram at all. The Symbio and G# UML tools make an excellent stab in that direction.

 

I mention this because rereading the above, I realized that someone might think I don't want a more graphical way to define classes. This is something I *definitely* want. I just don't think that a VI is the way to do it, and I don't think separate diagrams per class are the right way to go.

 

Just sayin'. :-)

[GregFreeman]

By the way... the data dump I did earlier missed one point.

 

Although I don't really like a single diagram for defining a class, a diagram for defining a class *hierarchy* is something I have a keen interest in. It would not look like an execution block diagram at all. The Symbio and G# UML tools make an excellent stab in that direction.

 

So I can visualize, are you talking like the class hierarchy window, although the ability to move the classes around to define inheritance, rather than going into the properties dialog and defining the inheritance structure in a tree control?

 

Edit: I should read more carefully -- The Symbio and G# UML tools make an excellent stab in that direction.

Edited June 19, 2013 by for(imstuck)