functional globals -> LVOOP

[WayneS1324]

Couldn't using functional globals be considered similar to OOP?

After all, they could be considered objects that have their own data sets.

[NIquist]

True, but that's just one aspect of encapsulation and there are other concepts missing for it to be considered a true definition of OOP.

[WayneS1324]

I wasn't thinking of it as true oop. Just similar. It was just a thought that occured to me.

[smercurio_fc]

Prior to LVOOP there was an early version of "object-oriented" used the functional global to manage multiple "objects" of a "class". I don't remember the name of the company that created the structure, but I know I had adapted it for the code I wrote. I modified for our own use here at work. So the idea is actually quite old.

[Ben]

---

WayneS1324 wrote:
Couldn't using functional globals be considered similar to OOP?

After all, they could be considered objects that have their own data sets.

---

As a self-taught OOPer, yes I agree. I suspect some formall OOPer may think otherwise.

I think it wasw Dr. Shane o'neal that taught me that Action Engines are actually something called "Componenet Orieneted Programming" rather than Object Oriented.

Setting the technical hair-splitting to the side for now...

I think of AEs and LVOOP apps as being one version being the other version turned inside out.

In a an AE the data is inside the AE.

In LVOOP the data (normally stored in a SR) is outside.

Although the AEs are easier to understand develop and support the LVOOP versions have some benefits that are mostly focused around the feature that changes to one class don't always require updates and re-testing of others. If none of the Vis (methods) in a calss don't get updated they do not re-tested. In an equivalent AE implementation, changing a action (method) results in the VI being resaved so the whole critter needs re-certified.

So there are many parallels and working with one approach can help understand the other.

Done rambling,

Ben

[Norbert_B]

FGVs (or also called Action Engines, as Ben pointed out) do indeed incorporate one important point of object orientated design: Data encapsulation.

Though you do not have any "access rights", the data kept in the shift register(s) is(are) private to the FGV.

But this is only a limited feature, rather a basis for OOP. OOP goes far beyond that: You need hierarchical structures for your classes and inheritance.

You should maybe read this white paper since it shows the basic info about LVOOP. Reading through it, you will see some "comparable features" to type definitions + FGVs, but as already said, LVOOP is much more.

hope this helps,

Norbert

[SteveChandler]

OOP is simply an approach to programming. You can do OOP in any language. An "OOP language" just gives you tools to enforce the rules of data access and to manage things such as inheritance.

[DFGray]

I would like to second SteveChandler's comment.  The real benefit of the current LabVOOP is that it makes it much easier to implement inheritance and enforce data access rules.  I have been programming LabVIEW in an object oriented manner for over a decade.  I started with the GOOP 1.0 toolkit to encapsulate my data.  I moved through action engines, single-element queues, and data value references as I learned about them and the features became available, ending up with LabVOOP, which actually enforces all the rules I was manually following before (but also uses a by-value model instead of a by-reference one).