Typesets and Class Design

[PJM_JKI]

---

@JackDunaway wrote:

---

@PJM_JKI wrote:

 There would need to be a lot of improvements made in the LabVIEW IDE before I would consider using classes for every cluster.

---

Can you elaborate on this?

---

I did start posting some stuff on this idea that you have on the idea exchange. I will copy (and expand on) what I said over there.

"I do like the idea of being able to directly access public class data just using an unbundler.

I understand Daklu argument, but one might say that if you want to run a private method (like a range checking) on a public data before exposing it that the previous data you run your check on was private data. Alternatively, you could associate (a little bit how you create property on XControl) a method to be run (behind the scene) when a user drop an unbundler.

Note: It is possible that this unbundler node may need to be different (might need to have error terminals).

I also like the idea of specifying the scope of individual class data member."

Additionally, I think that we should be able to see by value class data (instead of just a cube). The by value classes use a by reference visual concept (a customizable cube icon that refer to data) to represent them. I would love to be able to see a cluster like structure with all the public data.

Note: In the same fashion that there might be a method associated with an unbundler, there might be one associated with a bundler operating on the public data.

Next: I do not like how we manage lvlibs (and lvclass). LV is a graphical programming languages and we use tree control to edit classes (this feel like I am looking at a text programming IDE). There is a need for more graphical approach to these things. I am used, in LabVIEW, to see icon for my VIs. I lost that in the Tree Control implementation. I want to be able to do everything we do in an lvclass but in a graphical way (what about having the lvclass be like a VI BD that has Virtual Container where you can put your class method in it?). Also, we should be able to edit the inheritance hierarchy in a graphical way (see this idea). Additionally, I would love to be able to see class dependencies (association, composition, aggregation) in a graphical way (there is nothing available to visualize this at the moment in LabVIEW).

These ideas are far from flushed out, and I am sure I overlooked a lot of situations where this will be hard to do but this will be great if we could make using, editing an operating by value classes feel a lot more like "native" traditional LabVIEW.

[AristosQueue (NI)]

> Additionally, I would love to be able to see class dependencies (association, composition,

> aggregation) in a graphical way (there is nothing available to visualize this at the moment in LabVIEW).

This is why we asked Endevo (now Symbio) to build the UML tool. I wish it was part of LV itself, and I wish it wasn't coupled with the rest of the GOOP Dev Suite (because that encourages people to use the reference classes and burn themselves). But despite these drawbacks, it is a great tool, and it gives you the graphical relationship description/modification powers that you're seeking. I have worked with Mikael every LV release to make sure his tool works in the current version and gets rev'd for any new features that LV has added, and though I'm transitioning away from working on LV classes, I assume that support will be continuing through other members of my team. In time, LV will probably have something like this natively, but for now, that tool is what I would point you toward. And, yes, I'm aware that it costs money that you might not be able to afford. Again, I wish we had it as part of LV. There just aren't enough developers to cover all the hopes and dreams. *sigh*

[F._Schubert]

PJM, you reply posted above pushed me to write down my idea suggestion on showing class associations.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Graphically-display-Associations-in-the-Class-Hierarch...

Felix

[Ben]

Agreed.

UML is the natural answer to that need.

Ben

[JackDunaway]

---

Aristos Queue wrote:

...my opinion, typedef clusters are dinosaurs and the meteor is in the sky.

---

Alright, I took the challenge and developed a framework completely typedef-less.

(Well, not exactly true... I was forced to use a few typedefs for compatibility from the vi.lib such as LVPointTypeDef.ctl, imagedata.ctl, and then the typedefs associated with creating XControls such as Data, State...I didn't introduce any typedefs is a more accurate statement)

I challenge you to find a place in the framework where a typedef would be more elegant, more robust, or just more better. I really want to hear criticisms, especially from those who have responded in this thread, because this is the first time I've released a sizable amount of my code to be reviewed by the community. Be brutal. 

(I used strings for states in a state machine - that's one place where I'd rather not debate string vs. typedef'd enum, because both camps have good arguments)

While you're at it, send a vote my way 

[Ben]

---

@JackDunaway wrote:

---

Aristos Queue wrote:

...my opinion, typedef clusters are dinosaurs and the meteor is in the sky.

---

Alright, I took the challenge and developed a framework completely typedef-less.

(Well, not exactly true... I was forced to use a few typedefs for compatibility from the vi.lib such as LVPointTypeDef.ctl, imagedata.ctl, and then the typedefs associated with creating XControls such as Data, State...I didn't introduce any typedefs is a more accurate statement)

I challenge you to find a place in the framework where a typedef would be more elegant, more robust, or just more better. I really want to hear criticisms, especially from those who have responded in this thread, because this is the first time I've released a sizable amount of my code to be reviewed by the community. Be brutal. 

(I used strings for states in a state machine - that's one place where I'd rather not debate string vs. typedef'd enum, because both camps have good arguments)

While you're at it, send a vote my way 

---

Was I suposed to be able to find some code at that first link?

Ben

[JackDunaway]

---

@Ben wrote:

Was I suposed to be able to find some code at that first link?

Ben

---

Oops! Real link. I have the moderator making the changes to that original post.