Do you GOOP?

[Spencer]

I have been programming LabVIEW for about a year, and am starting to
get to the point where my programs are complex enough that I can get
myself in some real trouble and create some real hairy looking programs
if I'm not careful. So I've been trying to read up more on methods of
maintaining order and structure to my programs. In doing so I came
across the Graphical Object-Oriented Programming application note, and
then the software download. It seems to add structure, but I don't
like to use wizards to create stuff, they never seem to be an exact fit
for what I'm doing. It seems to be a pretty big departure from what
I'm doing, with a learning curve that could take a little while. I can
do the class and object thing in C++ without much t
rouble.

So, has anybody out there tried implementing it? Is everybody doing it
and I just didn't know about it until now? Is it worth it? I'd be
interested in answers. Any GOOP believers out there that wouldn't mind
sharing some example code so I can see some implementation?

If you don't GOOP (or if you do), how do you handle programs that allow
the user to make a lot of decisions (many buttons, controls, etc.)? My
diagrams get so full of case statements and wires that it gets jumbled
in a hurry. If you can share any examples you are proud of, I'd love
to see some of the better more elegant implementations.

Thanks

Spencer
spencerwa@hotmail.com


Sent via Deja.com http://www.deja.com/
Before you buy.

[Kevin_work]

Spencer wrote:

>

[snip]

> If you don't GOOP (or if you do), how do you handle programs that allow
> the user to make a lot of decisions (many buttons, controls, etc.)? My
> diagrams get so full of case statements and wires that it gets jumbled
> in a hurry. If you can share any examples you are proud of, I'd love
> to see some of the better more elegant implementations.
>
> Thanks
>
> Spencer
> spencerwa@hotmail.com
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Spencer,
Maybe I am hard of thinking, but I dont see that much advantage to using
GOOP
in my typical applications. I think OOP has it's place, but I think many
times it is
used simply because it exists not because it is the best solution.

Looking at the NI stuff on GOOP it appears that th
ey are comparing bad
LabVIEW
to good GOOP. Not very informative in my opinion.
I followed most of the guidelines in these documents using straight LabVIEW
and came
out with the same results, only smaller and faster. My last large
application has about
50 different controls that the user can change, they can't manipulate them
all at once
so why present them all ??

My implemetation led to a top level with 6 buttons, 5 of which led to subVIs
where more
controls are presented. Of course I suppose you could think of subVIs as
objects so
maybe it is already OOP.

I have always found the best advice to people about these types of questions

is "Go with what works for you".
Kevin Kent

[Ravi Narasimhan]

In article <39920A0B.F45F8D0D@usa.alcatel.com> "Kevin B. Kent" writes:
>Spencer wrote:
>[snip]
>
>> If you don't GOOP (or if you do), how do you handle programs that allow
>> the user to make a lot of decisions (many buttons, controls, etc.)? My
>> diagrams get so full of case statements and wires that it gets jumbled
>> in a hurry. If you can share any examples you are proud of, I'd love
>> to see some of the better more elegant implementations.

>> Thanks
>>
>> Spencer
>> spencerwa@hotmail.com
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.
>
>Spencer,
>Maybe I am hard of thinking, but I dont see that much advantage to using
>GOOP
>in my typical applications. I think OOP has it's place, but I think many
>times it is
>used simply because it exists not because it is the best solution.
....
[ Deletia ]

Some opinions from an occasional-to-moderate LV user. Corrections of
misperceptions appreciated:

I looked at the LV GOOP documents and worked through the examples presented
there and also looked up some other introductions to OOP based on C++ and
Java. My first impression is that [G]OOP imposes overhead and it was
not clear to me where the payoff came, at least on the scale in which I write
and maintain code. With reference to LV and DAQ in particular, I did not see
how the process of isolating data from methods and the like
affects the issues such as:

1) Trying to understand complex diagrams with many cases and conditions,
especially those written by others
2) Understanding how dataflow and interrupts work together
3) Talking to hardware and the timing issues that crop up

3) has given me some troubles recently as I was working with serial I/O and
with buffered DAQ. The specific methods of implementing solutions required
going into VIs that talked to hardware and adding waitstates so that the CPU
did not get hogged by one process over all the others.

It was always my impression that waitstates were considered very bad
programming practice as they make a program highly processor dependent. I
would think that many of the areas in which GOOP is to have a major impact
such as multiprocessor and/or networked execution would still depend
critically on low-level routines and drivers which require specific attention
to processor and configuration details. I believe it is only recently, with
the beta release of VISA, that asynchronous serial I/O is implemented, for
example.

One place where I have seen some immediate usefulness of GOOP came from
James Kring's timer VIs, posted to this group about a week ago. These VIs add
some functions to LV that I needed and I have been using them with
success. The key advantage is that reentrancy seems to be handled
transparently. Create a timer, use it, destroy it and have as many as you
need running simultaneously. James informed me in email that he used GOOP
philosophies but not the Wizards in creating his code. His company's website
(http://www.calbay.com) has some nice tips on state-machine architecture which
I think will be more important to me in the short term than [G]OOP.

Based on what I have read, [G]OOP is akin to the Pointy-Haired Boss management
philosphy in which hierarachies are created for their own sake and in which
the low-level tasks of getting something done are considered much less
important. The Org charts do look pretty, though. I'd like to echo Kevin's
statement that locals and globals do not appear to be intrinscially evil
things. Ultmately they were the only way I could get some recent code
implemented.

Again, these opinions could be off-base and I'd be interested in comments from
those who have successfully used these practices.

--- Ravi Narasimhan
--
Ravi Narasimhan
Dept. of Physics and Astronomy, UCLA
http://www.physics.ucla.edu/~oski
oski@physics.ucla.edu

[Paul]

Yes, I use GOOP. My project is industrial automation. I use
BridgeVIEW which is LabVIEW with an integrated industrial automation tool
kit. The object oriented features of GOOP are perfect for a manufacturing
cell because everything in the cell can be represented as an object. For
example, I have a cell class, a class for each machine in the cell, a plc
class to handle communications with the machines' plc's, a Statistics class
to calculate information from the plc data, etc...
There are big advantages in using GOOP. First of all is the
organization. My program is very structured and the entire program is
documented in a class diagram. The next person who takes the project over
from me will have no problem understanding what I was doing unlike the pile
of spaghetti that I inherited. Second is portability. Since most
manufacturing cells are similar, it is easy to modify a current program
when introducing industrial automation to a cell.
I think GOOP is great and I don't ever plan on not using GOOP. That
said, I am a beginner LabVIEW programmer so I don't have many bad habits to
overcome but I also don't know all there is to know about LabVIEW and its
many uses. GOOP may not be the answer to every application dilemma but it
works great for mine.

Spencer wrote:

> I have been programming LabVIEW for about a year, and am starting to
> get to the point where my programs are complex enough that I can get
> myself in some real trouble and create some real hairy looking programs
> if I'm not careful. So I've been trying to read up more on methods of
> maintaining order and structure to my programs. In doing so I came
> across the Graphical Object-Oriented Programming application note, and
> then the software download. It seems to add structure, but I don't
> like to use wizards to create stuff, they never seem to be an exact fit
> for what I'm doing. It seems to be a pretty big departure from what
> I'm doing, with a learning curve that could take a little while. I can
> do the class and object thing in C++ without much trouble.
>
> So, has anybody out there tried implementing it? Is everybody doing it
> and I just didn't know about it until now? Is it worth it? I'd be
> interested in answers. Any GOOP believers out there that wouldn't mind
> sharing some example code so I can see some implementation?
>
> If you don't GOOP (or if you do), how do you handle programs that allow
> the user to make a lot of decisions (many buttons, controls, etc.)? My
> diagrams get so full of case statements and wires that it gets jumbled
> in a hurry. If you can share any examples you are proud of, I'd love
> to see some of the better more elegant implementations.
>
> Thanks
>
> Spencer
> spencerwa@hotmail.com
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

[Andrew J Steinbach]

While I haven't used GOOP yet, I am developing my own GOOP for use
in my applications. I've read through the documentation for GOOP, and
some of the concepts between GOOP and my GOOP are similar.
The object handle (pointer) concept in GOOP is very powerful.
Being able to refer to a group of VIs contained within the object by a
single handle variable greatly reduces program complexity. One can build
arrays of object handles, allowing very easy handling of multiple
instances of the object. If applications are properly written, adding
additional objects is very trivial, and can be done at run-time. This
provides the user with greater flexibility, without any additional
development time.
In addition, data handling becomes much easier. Instead of having
to build arrays (or worse, global variable arrays) to keep track of data,
one can access all of the data simply through the object handle.
Some additional functionality would greatly add to GOOP's utility.
One thing I don't like is that each type of GOOP object is different from
the others. IE, GOOP object "A" will have certain methods and properties,
while GOOP object "B" will have completely different methods and
properties. My version of GOOP will provide a common interface for all
objects. When the object is initialized, the return information includes
a list of all available methods and properties. This provides a seamless
way to allow the user to select the available methods and properties
without writing custom code for each object.

Andy

Spencer (sw_anderson@my-deja.com) wrote:
: I have been programming LabVIEW for about a year, and am starting to
: get to the point where my programs are complex enough that I can get
: myself in some real trouble and create some real hairy looking programs
: if I'm not careful. So I've been trying to read up more on methods of
: maintaining order and structure to my programs. In doing so I came
: across the Graphical Object-Oriented Programming application note, and
: then the software download. It seems to add structure, but I don't
: like to use wizards to create stuff, they never seem to be an exact fit
: for what I'm doing. It seems to be a pretty big departure from what
: I'm doing, with a learning curve that could take a little while. I can
: do the class and object thing in C++ without much trouble.

: So, has anybody out there tried implementing it? Is everybody doing it
: and I just didn't know about it until now? Is it worth it? I'd be
: interested in answers. Any GOOP believers out there that wouldn't mind
: sharing some example code so I can see some implementation?

: If you don't GOOP (or if you do), how do you handle programs that allow
: the user to make a lot of decisions (many buttons, controls, etc.)? My
: diagrams get so full of case statements and wires that it gets jumbled
: in a hurry. If you can share any examples you are proud of, I'd love
: to see some of the better more elegant implementations.

: Thanks

: Spencer
: spencerwa@hotmail.com


: Sent via Deja.com http://www.deja.com/
: Before you buy.

--
Andy Steinbach
stei0113@tc.umn.edu

[Jörgen Jehander]

Hi Spencer,

GOOP is a great tool for decomposing your LabVIEW applications since it
brings the class mechanism to the G language. The class mechanism makes
it possible to express the parts that constitute the application
problem. Since a GOOP class contains several VI�s it makes it much
easier to get a better description of a large LabVIEW program. A
LabVIEW program can be described by using the UML, Unified Modelling
Language, which is the standard object-oriented design notification.

Another important thing about GOOP is that it connects to
object-oriented community and thus makes it possible to re-use and
leverage of good design techniques.As you know there are several books
about object-oriented programming...

Here in Sweden GOOP has been deployed a lot at big customers like
Ericsson. We have also educated about 100 people here in Sweden about
GOOP programming.

I agree that there is not enough information available about GOOP but I
hope that this situation will be resolved soon. A good place to put the
information would probably be the NI developer zone. But for now I would
recommend exploring books about object-oriented programming. Normally I
take good object-oriented design patterns and bring them to LabVIEW by
using GOOP. I often find this design patterns in projects I have worked
in or books.

J�rgen Jehander
Jorgen.Jehander@endevo.se


In article <8msnv4$fc4$1@nnrp1.deja.com>,
Spencer wrote:
> I have been programming LabVIEW for about a year, and am starting to
> get to the point where my programs are complex enough that I can get
> myself in some real trouble and create some real hairy looking
programs
> if I'm not careful. So I've been trying to read up more on methods of
> maintaining order and structure to my programs. In doing so I came
> across the Graphical Object-Oriented Programming application note, and
> then the software download. It seems to add structure, but I don't
> like to use wizards to create stuff, they never seem to be an exact
fit
> for what I'm doing. It seems to be a pretty big departure from what
> I'm doing, with a learning curve that could take a little while. I
can
> do the class and object thing in C++ without much trouble.
>
> So, has anybody out there tried implementing it? Is everybody doing
it
> and I just didn't know about it until now? Is it worth it? I'd be
> interested in answers. Any GOOP believers out there that wouldn't
mind
> sharing some example code so I can see some implementation?
>
> If you don't GOOP (or if you do), how do you handle programs that
allow
> the user to make a lot of decisions (many buttons, controls, etc.)?
My
> diagrams get so full of case statements and wires that it gets jumbled
> in a hurry. If you can share any examples you are proud of, I'd love
> to see some of the better more elegant implementations.
>
> Thanks
>
> Spencer
> spencerwa@hotmail.com
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.