mgould2001

We've found that our software tools for our manufacturing floor have a habit of being sold by our service department to 3rd party repair centers, so we do care about licensing. Basically it sounds like OpenG is more trouble than it's worth (in our case).

I looked at VPIM's openG license and it looks like they credit individual people.  Are these the guys who wrote the specific VI's that JKI used or are they just the guys who made openG?  Do I have to go through every openG VI to figure out if I used a specific persons work and specifically credit them?

I think I'm more confused about openG licensing than before I read this thread :-).  I hate to be that guy but can anyone, in three sentences or less, describe to me what I need to do to not get sued if I include openG functions in my software?  I would really like to use this in our software, but as a commercial company our lawyers are frightened by the licensing requirements of open source software.  If I could at least understand the minimum requirements we might be able to persuade them otherwise.  I've looked at the openG functions and they look amazing so I'm really excited about using them!

Thanks for the commend, I have seen composition used before and I should have included it.

So is that (Composition) the standard way of dealing with objects that have some things in common but something that are not?  I'm just really curious because this seems to come up a lot in the couple years we've been using LabVIEW OOP, especially when you are developing HALs.  For example lets say you have a power supply class.  Most power supplies have a init, close, set voltage, set current, etc but occasionally you'll come across one that has additional (useful) functionality that the others don't have.  If I want to make use of that additional functionality, do I start a whole new class hierarchy?  If I do that then I've broken my power supply HAL.  It seems like this should be solvable with OOP since its designed to EXTEND functionality of a class. 

BTW, bark and meow were bad examples.  I should have used something like cats can claw and dogs can track.  Two totally unrelated functions that you can't easily attribute to just any animal.

Lets say I have a class hierarchy like this:

NOTE:  Stole this hierarchy from this thread because it was helpful in understanding my problem.

The classes have functions that look like the below.  The intent is that any animal can have a name but only dogs can bark and only cats can meow. There is also a "Find Animal" VI that takes an array of animals and finds the first object with the provided name.

 
And I use it to write code that looks like this:

Obviously after the find animal I have a broken wire because any animal can come out of the find animal and the compiler cant guarantee that the "Meow.vi" will work on every animal since it is a method of the felidae class.

It is my understanding I have one of two choices at this point:

A:  I can add "Meow" and "Bark" as methods to the parent class, and make them dynamic dispatch.  I've done this with projects in the past and everything works fine.  The only problem is you end up with enormous parent classes that have tons of methods that don't do anything.  It also "feels wrong" because I don't like the idea of having a ton of placeholder code.

B:  You do something like this:

In this case you are guaranteeing the compiler that at run time there will be a specific class on that wire and that it can take it to the bank.  If it turns out that the class on the wire is the wrong type, we give it an out with a error handling case.  I'm a little uncomfortable with this type of code because I haven't done a lot of it, but I don't know how well it scales.  My question to you all is, "Am I correct in my understanding or is there a better way to deal with this case?"   Thanks, and I'll attach the proj to this thread.

Animal House Example.zip