GOOP

[j.osbeck@telia.com]

Hello !

I'm considering to start GOOP-programming with LabVIEW, does anyone
have some expericens to share.

- Is it a better way or is the "overhead" of learing GOOP to big ?

Best regards

/Joachim (Sweden)

[Sven Hädrich]

Hi Joachim,

I invested about half a year in
programming GOOP. I knew the basic
ideas of object orientation already from
the C++ environment. I think it is a
necessary step to use object oriented
programming methods if you need to
code "big" applications. GOOP gives you
the power to use "local" variables when
programming in G. This helps a lot to
create encapsulated objects. The great
drawback is that LabVIEW, unlike C++,
produces by default no completely
reantrant code. To illustrate the
consequences to you: if you create a
dialog VI (that is a VI that pops up and
allows some kind of user interaction) you
can only have one dialog window on your
screen at a time. This is very different to
C++ where you can create another
instance of a dialog objec
t that would be
completely independent of other
instances. Another source of problems is
that LabVIEW code is not reentrant by
default, which means you have to think by
yourself which VIs might be executed
parallel by your application.
To summarize ,I would put it this way:
using a object oriented approach is a
good way to create good programs,
GOOP can support you in this effort, but
LabVIEW has some way to go to support
object orientation fully.

j.osbeck@telia.com wrote:
>Hello !>>I'm considering to start
GOOP-programming with LabVIEW, does
anyone>have some expericens to
share.>>- Is it a better way or is the
"overhead" of learing GOOP to big
?>>Best regards >>/Joachim (Sweden)>

[Jörgen Jehander]

In article <3a4b9786.18163793@news1.telia.com>,
j.osbeck@telia.com wrote:
> Hello !
>
> I'm considering to start GOOP-programming with LabVIEW, does anyone
> have some expericens to share.
>
> - Is it a better way or is the "overhead" of learing GOOP to big ?
>
> Best regards
>
> /Joachim (Sweden)
>
>

Joachim,

GOOP programming is all about learning how to use object-oriented,oo,
thinking when decomposing a problem. As you know, oo thinking is
associated with most successful programming languages like C++, Java. So
there is obviously a reason for using oo programming!

Learning GOOP is very easy when you have a better understanding of the
oo stuff. In order to use GOOP effectively in LabVIEW you have to learn
the GOOP mechanics. The GOOP mechanics consists of
the wizard together
with some specific help VIs used for managing objects in LabVIEW.

The GOOP mechanics is easy to learn but the OO stuff takes some more
time.

Jörgen


Sent via Deja.com
http://www.deja.com/

[Abdullah Rafiq]

Hi Joachim,

I would agree with what is said earlier by Sven. The thing i like about GOOP
is
1)the ease of creating object reference. Object reference encapsulates all
the data that you might want to transfer from one VI to the other.
2)Changes of your existing code are much easier using GOOP.
3)Its best option for larger codes specially when you know that you might
be adding something to your code in the future.

The downside is that you can NOT truely instanciate multiple objects like
you can in C++ or JAVA.

regards,
Abdullah

[Wim Hoeijenbos]

Joachim,

I just started using labview and I also adapted the GOOP method. Although I
work with Labview5.1 it was very easy to use standard OOP design concepts
(UML) in LabView.

It is more work to learn this OO analysis and design concepts than it is to
learn to use GOOP.

One of the big advantages of OO programming in C++, JAVA etc is the
inheritance of membervars/methods from parent Class to Child. This is as far
as I know not possible in GOOP.

Success

Wim (Holland)


wrote in message
news:3a4b9786.18163793@news1.telia.com...
> Hello !
>
> I'm considering to start GOOP-programming with LabVIEW, does anyone
> have some expericens to share.
>
> - Is it a better way or is the "overhead" of learing GOOP to big ?
>
> Best regards
>
> /Joachim
(Sweden)
>

[Joel Andersen]

Hello Joachim,

For a great starting point, I recommend that you look at National Instruments'
Application Note 143. It covers many GOOP related topics. You can find
it by searching the KnowledgeBase under GOOP. If you have any problems finding
it, then just follow this link: http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/162415e05fc2543786256865006c1ea0?OpenDocument

Joel Andersen

"Wim Hoeijenbos"
wrote:
>Joachim,>>I just started using labview and I also adapted the GOOP method.
Although I>work with Labview5.1 it was very easy to use standard OOP design
concepts>(UML) in LabView.>>It is more work to learn this OO analysis and
design concepts than it is to>learn to use GOOP.>>One of the big advantages
of O
O programming in C++, JAVA etc is the>inheritance of membervars/methods
from parent Class to Child. This is as far>as I know not possible in GOOP.>>Success>>Wim
(Holland)>>> wrote in message>news:3a4b9786.18163793@news1.telia.com...>>
Hello !>>>> I'm considering to start GOOP-programming with LabVIEW, does
anyone>> have some expericens to share.>>>> - Is it a better way or is the
"overhead" of learing GOOP to big ?>>>> Best regards>>>> /Joachim (Sweden)>>>>

[Alex]

[posted and mailed]

wim@hoeijenbos.demon.nl (Wim Hoeijenbos) wrote in
<978959759.8179.0.pluto.c3adf994@news.demon.nl>:

>One of the big advantages of OO programming in C++, JAVA etc is the
>inheritance of membervars/methods from parent Class to Child. This is as
>far as I know not possible in GOOP.

AFAIK Jorgen Jehander has previously written in this newsgroup that this is
possible. The technique is called inheritance by delegation, and involves
embedding the derived classes in the base class and using an attribute that
decides which embedded class to call.

Perhaps Jorgen can explain this further.


--

Alexander C. Le Dain, PhD
ICON Technologies Pty Ltd
http://www.icon-tech.com.au

******************************************************************
* The Lab
VIEW FAQ http://www.icon-tech.com.au/thelabviewfaq.html *
******************************************************************

[Jörgen Jehander]

In article <90268DDEBaledainupnawaycom@203.59.24.169>,
nospam@nospam (Alex) wrote:
> [posted and mailed]
>
> wim@hoeijenbos.demon.nl (Wim Hoeijenbos) wrote in
> <978959759.8179.0.pluto.c3adf994@news.demon.nl>:
>
> >One of the big advantages of OO programming in C++, JAVA etc is the
> >inheritance of membervars/methods from parent Class to Child. This is
as
> >far as I know not possible in GOOP.
>
> AFAIK Jorgen Jehander has previously written in this newsgroup that
this is
> possible. The technique is called inheritance by delegation, and
involves
> embedding the derived classes in the base class and using an attribute
that
> decides which embedded class to call.
>
> Perhaps Jorgen can explain this further.
>
> --
>
> Alexander C. Le Dain, PhD
> ICON Technologies Pty Ltd
> http://www.icon-tech.com.au
>
> ******************************************************************
> * The LabVIEW FAQ http://www.icon-tech.com.au/thelabviewfaq.html *
> ******************************************************************
>
>
Inheritance in GOOP

Abstract

By utilizing the power of inheritance in LabVIEW, the programs become
more flexible and easier to maintain.

General theory

Object-oriented programming extends classes to allow for subclass
relationships. This is achieved through a mechanism referred to as
inheritance.

Let us illustrate this by having two classes called Function_Generator
and HP33120A. HP33120A is a specialization of a function generator since
it represents a real generator. Using the inheritance mechanism we would
have the HP33120A to be a subclass to the base class,
Function_Generator. This means that the HP33120A class will inherit
behaviour, methods, from the Function_Generator class. In many cases you
put common code for all subclasses in the base class that is reused by
the subclasses. In our example it could be code handling the GPIB
communication to all different types of function generators. The
different strings used for instrument specific commands are handled in
the subclasses, in our case the HP33120A class.
Let us add a method called Frequency to both classes.

Think of some test cases only interested in setting the frequency of a
function generator. The test cases do not want to be affected when new
function generators are added. How do you program that? Traditional
LabVIEW code would access the HP33120A directly. So what would happen if
the function generator is changed to a Tektronix AWG 2041generator. We
would have to change all code using the HP33120A. Is not there a smarter
way to hack this? The trick is to use the powerful inheritance scheme
and add a TEK_AWG_2041 subclass . Let the code in the test cases only
call a Function_Generator object. When the code is actually executed the
Function_Generator object is transformed into the right type of function
generator, in our case a HP33120A or a TEK_AWG_2041 object. The key
thing is that the transformation to exact type of object is done in run
time and not when you place the code in the block diagram. This means
that the block diagram code for the test cases only contains code for
handling a Function_Generator. Normally this transformation scheme is
called dynamic binding since the actual binding is done in run time. The
beauty with that is that the code in the test cases will not be affected
when new types of function generators are added to the system. When a
new function generator is added it only has to be defined at one place
in the program, not in all test cases. The code becames robust for
changes and that makes the code easier to maintain.

Inheritance is based primarily on these two concepts:

1. An inheritance relationship between a base class and its subclasses
2. Dynamic binding

Inheritance in GOOP

The GOOP model today cannot implement the concepts above directly so
they have to be simulated. A technique called "Inheritance by
deligation" is used.

An aggregation relationship is used to implement the inheritance
relationship. A base class aggregates, embedds, its subclasses. In our
example the Function_Generator class would aggregate the HP33120A and
the TEK_AWG_2041 classes.

The dynamic binding is done inside the base class. An attribute, private
data member, called current subclass is added to the base class. An
enumerated type is used for the current subclass attribute and the
integral constants are the names of the subclasses. This attribute
controls the dynamic binding in the following way. When a call is done
to a method in the base class a check is done on value of the current
subclass attribute. Depending on the value the call is dispatched,
deligated, to the right type of subclass object.

In our example we would rename the attribute to current function
generator and it would contain two integral constant called HP33120A and
TEK_AWG_2041.

Summary

A drawback with the simulation model for inheritance in GOOP is that it
is more time consuming to manage as compared to true inheritance in
languages like C++ and Java. Anyway, the benefit from using inheritance
in LabVIEW greatly exceeds the time it takes to learn and deploy it. By
using it large LabVIEW projects becomes feasible to maintain.


Sent via Deja.com
http://www.deja.com/

[paracha3@my-deja.com]

inheritance is actually possible in GOOP. You can find an example on
that on NIs website (Developer Zone)

Abdullah Rafiq


In article <978959759.8179.0.pluto.c3adf994@news.demon.nl>,
"Wim Hoeijenbos" wrote:
> Joachim,
>
> I just started using labview and I also adapted the GOOP method.
Although I
> work with Labview5.1 it was very easy to use standard OOP design
concepts
> (UML) in LabView.
>
> It is more work to learn this OO analysis and design concepts than it
is to
> learn to use GOOP.
>
> One of the big advantages of OO programming in C++, JAVA etc is the
> inheritance of membervars/methods from parent Class to Child. This is
as far
> as I know not possible in GOOP.
>
> Success
>
> Wim (Holland)
>
> com> wrote in message
> news:3a4b9786.18163793@news1.telia.com...
> > Hello !
> >
> > I'm considering to start GOOP-programming with LabVIEW, does anyone
> > have some expericens to share.
> >
> > - Is it a better way or is the "overhead" of learing GOOP to big ?
> >
> > Best regards
> >
> > /Joachim (Sweden)
> >
>
>


Sent via Deja.com
http://www.deja.com/

[joeyoravec]

wrote in message news:93lfq7$2ic$1@nnrp1.deja.com...
> inheritance is actually possible in GOOP. You can find an example on
> that on NIs website (Developer Zone)

Unless I'm mistaken, I had only seen a dervied class example not true
inheritance. I saw reference to somebody writing a decision VI before which
determines the priority for the functions (ie. does the child have
functionA? if no does the parent have functionA?) but a lot of true OO is
lacking in goop.

A good start nonetheless, most of the C++/Java OO functionality could be
simulated assuming resources are unlimited. It still drives me crazy the
things LV lacks. I have a Lippmann book on the object model we used in class
once which summarized OO languages as havi
ng inheritance, polymorphism, and
encapsulation.

They certainly have some aspects of encapsulation nailed with GOOP, but even
that I am having great difficulty with things that need to be visible on the
front panel but actually should be object public member variables. Never
seen examples for this.

Haven't seen inheritance done but perhaps it's my problem. Feels nontrivial.

And finally polymorphism sure 6i markets that it supports polymorphism but
it feels nothing like the power of C++/Java and I've never seen how to do
pure virtual or virtual functions and nobody responded to my last posting
about it. I assume it can't be done.

Finally.... I would love to see some discussion about how to do stuff with
Goop. All I ever see is every 2 weeks somebody post a topic (Re: GOOP
exactly like this one) asking if it's any good. I'd love to see some of
these fallings corrected and some great discussion.

-joey