Object oriented programming in LabVIEW

[User002]

Please send this message to everybody who has an opinion about this.

Please try to keep it short, but if you can't control yourselves, let
it all out!

I would like to have your opinions about the nature of Labview and it's
ability to support object oriented programming.

I have a couple of questions to fire the discussion.

1- Do you think that LV was built to support OO Programming?
2- Is OO the only way we have to support large applications, or is it
feasible to support it with a good dataflow architecture including all
the flowcharts and all the data definitions?
3- Is LV going to stay "dataflow" or is it going to become OO?
4- What would be the great benefits of turning LV to OO that we don't
already have w
ith the dataflow approach?
5- My opinion is that trying to implement OO in LabVIEW, is like trying
to

Thank you all for your time.


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

[Abdullah]

Labview wasn't built to directly support OOP. Infact the OOP in labview is not exactly the OOP in other languages like JAVA and C++. Meaning when you instantiate a VI, you are not actually allocating memory for it or creating multiple instances of the same object. Its just a better way of locking and encapsulation. However i do agree that its a good approach if you want your software to be reuseable and mentainable. When you create data memebers in GOOP, you are essentially creating a common interface which other member function can read or modify. VI server has introduced sort of object paradigm in a sense that you can manipulate properties and methods and you can open multiple references to a VI.

Also use inheritance in labview VI which is object references embedde
d in other objects.

I can't say for sure but i would think that labview will stay mainly dataflow. But if i were to start a new project and i know that someone else will work on it the future, i'd certainly look into possibility of implementing it thru GOOP (Graphical Object Oriented Programming).

hope this helps!
Abdullah

[Günter Hofmann]

Dominic Lavoie wrote:

> Please send this message to everybody who has an opinion about this.
>
> Please try to keep it short, but if you can't control yourselves, let
> it all out!
>
> I would like to have your opinions about the nature of Labview and it's
> ability to support object oriented programming.
>
> I have a couple of questions to fire the discussion.
>
> 1- Do you think that LV was built to support OO Programming?

The user interface of LV is object orientated, but the language is
definitly not.
From my point of view the LabView language (G) is a little bit like a
functional
programming language.

>
> 2- Is OO the only way we have to support large applications, or is it
> feasible to support it with a good dataflow architecture including all
> the flo
wcharts and all the data definitions?

No OO ist not the only way to support large applications. I think LV
ist well suited for the development of large applications.

>
> 3- Is LV going to stay "dataflow" or is it going to become OO?

I think LV will stay "dataflow" because thats its nature. Making LV OO
would be building a new language.

>
> 4- What would be the great benefits of turning LV to OO that we don't
> already have with the dataflow approach?

I don't know ?

>
> 5- My opinion is that trying to implement OO in LabVIEW, is

not necessary, if someone needs OO and has enough time he should
use a purley OO language.

>

>
> Thank you all for your time.
>
> Sent via Deja.com
> http://www.deja.com/

best regards

Günter Hofmann
--
____________________________________________________________________

Dipl.-Math. Günter Hofmann | Fraunhofer Gesellschaft IIS-A
Phone: +49-(0)9131-776-6324 | Am Weichselgarten 3
mailto:hfn@iis.fhg.de | D-91058 Erlangen
http://www.iis.fh
g.de | Germany
____________________________________________________________________

[Stu 708]

Good question. The answer will depend on what your definition of OO is.
(how is that for Clinton speak)
I would say that you can practice OO techniques with LabVIEW just as you can
with other procedural languages.

The data flow, typedefs and VI as a module help the situation. New to 6 are
polymorphic VIs and variant typedef support.
There are not build in mechanisms to the language to help with the full
features of a OO language like C++.

In spite of these pure OO limitations we use OO techniques for most of our
code development.
Modules with methods and data encapsulation are the most common OO
techniques we use.

Over time, we have developed tools and techniques that facilitate object
cloning, named objects and data structure browsing
that we use on most pro
jects. More of these abilities could be added to
future revs of LabVIEW.

More comments follow

>
> 1- Do you think that LV was built to support OO Programming?
Full OO programming, no. Supports OO methods, yes. Improving, yes.

> 2- Is OO the only way we have to support large applications, or is it
> feasible to support it with a good dataflow architecture including all
> the flowcharts and all the data definitions?

It is definitely possible to support large maintainable applications with
LabVIEW. We use OO methods
to manage the complexity.
I would also believe that the tool alone is not the critical element to the
success of any given project.

> 3- Is LV going to stay "dataflow" or is it going to become OO?
What is OO in this context? What features of OO are missing that you need
to solve a given problem?

> 4- What would be the great benefits of turning LV to OO that we don't
> already have with the dataflow approach?

My question as well.

Stu

> 5- My opinion is that trying
to implement OO in LabVIEW, is like trying
> to
>

[jan_klasson@my-deja.com]

In article <959atl$elf$1@nnrp1.deja.com>,
Dominic Lavoie wrote:
> Please send this message to everybody who has an opinion about this.
>
> Please try to keep it short, but if you can't control yourselves, let
> it all out!
>
> I would like to have your opinions about the nature of Labview and
it's
> ability to support object oriented programming.
>
> I have a couple of questions to fire the discussion.
>
> 1- Do you think that LV was built to support OO Programming?
No.
> 2- Is OO the only way we have to support large applications, or is it
> feasible to support it with a good dataflow architecture including all
> the flowcharts and all the data definitions?
A LabVIEW program is basically structured in the same way as any other
program built with a language that use functions (VIs) to brake down a
problem (like C or the original versions of Pascal). The drawback with
this approach is that when two VIs/functions need to share data you will
introduce a global datastructure to support this. As the application
grows you will end up with a lot of global data and a lot of VIs
depending on this global data. This program will become harder and
harder to maintain, if you change the datastructure you will have to
find all VIs using this datastructure and modify them.
This problem is the reason why modules (like classes) where introduced
in languages lika ADA (in the 80s!), C++, Simula, Smalltalk and later on
Java. Modules where introduced to support encapsulation of data, the
data should only be accessed via the modules public methods.
Building applications in this way using OO languages has become
mainstream and best practice during the 90s.
For some reason the Labview community believes they are immune against
these well known problems and have some religious belief that dataflow
will solve the problem. It will not.
> 3- Is LV going to stay "dataflow" or is it going to become OO?
Is Labview going to survive and be a tool that can be used in big
applications? Or should it be mainly a tool for quickly building small
applications? GUIs are easily built in LabVIEW but more advanced GUIs
with Windows look&feel are better built in VB. ActiveX components with
high performance can be built with C++. You can use VB or Java scripts
to give a WEB interface to the application. Etc, etc. There are many
options. LabVIEW is a very good tool but there are alternatives to
consider.
> 4- What would be the great benefits of turning LV to OO that we don't
> already have with the dataflow approach?
Look at the answer to question 2.
> 5- My opinion is that trying to implement OO in LabVIEW, is like
trying
> to
>
There is no contradiction between OO and dataflow they can coexist!
> Thank you all for your time.
>
> Sent via Deja.com
> http://www.deja.com/
>

I have worked with OO for the last 10 years and build OO applications
both in Labview and C++/Java. The current Labview application I'm
working with has about 4500 VIs. Using OO has made it possible to make
this product maintanable. I wouldn't like to try it without OO.

The LabVIEW community must wake up and look at what is happening outside
their narrow walls.

Regards
Jan Klasson
Consultant at Endevo AB


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

[Hedgehog]

If you look on the NI web-site there are some articles / code that you
can get for something called GOOP which explores some of the concepts
of OOP under labVIEW. Speaking recently with one of NI's senior labVIEW
architects, he reckons that they are exploring the possiblility of
incorporating OOP features into LabVIEW natively but if it happened it
wouldn't be for a few versions yet.


In article <959atl$elf$1@nnrp1.deja.com>,
Dominic Lavoie wrote:
> Please send this message to everybody who has an opinion about this.
>
> Please try to keep it short, but if you can't control yourselves, let
> it all out!
>
> I would like to have your opinions about the nature of Labview and
it's
> ability to support object oriented programming.
>
> I have a c
ouple of questions to fire the discussion.
>
> 1- Do you think that LV was built to support OO Programming?
> 2- Is OO the only way we have to support large applications, or is it
> feasible to support it with a good dataflow architecture including all
> the flowcharts and all the data definitions?
> 3- Is LV going to stay "dataflow" or is it going to become OO?
> 4- What would be the great benefits of turning LV to OO that we don't
> already have with the dataflow approach?
> 5- My opinion is that trying to implement OO in LabVIEW, is like
trying
> to
>
> Thank you all for your time.
>
> Sent via Deja.com
> http://www.deja.com/
>


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

[Greg_McKaskle2]

> 1- Do you think that LV was built to support OO Programming?

LV was initially designed in 1983. OOP existed at that point,
but LV wasn't designed to be OO. It was designed to allow
engineers and researchers a simple language appropriate
for controlling their research labs from a computer.

> 2- Is OO the only way we have to support large applications, or is it
> feasible to support it with a good dataflow architecture including all
> the flowcharts and all the data definitions?

OO lends itself to large projects because it provides
abstraction, encapsulation, and organizes code into
modules that can more easily be implemented independent
of one another since they can be specified in finer
detail. Also, the compilers help to enforce the
specifications providing they can be encoded in the
interface between objects.

These OO principles were already a part of big projects
long before there were OO languages. It was just that
the language didn't necessarily have features which
supported it. Similarly, they can be a part of big
projects today despite the language being used.

LV 2 style globals, which as the name suggests were
in use long ago, encapsulate data with an interface.
They disallow arbitrary access to the data and can be
used to enforce correct access. With other functions
layered on top, you get a nice interface to stored data.

Functions and structs/clusters abstract away details.
Building a subVI that does an FFT means that for 99%
of the uses, you don't need any more information except
that this block performs an abstract mathematical function,
an FFT. The implementation can be completely changed
to speed it up or make it more accurate and your code
isn't affected. Its abstract definition still holds, so
your code still works.

There are other things that OO languages bring to the
table that LV, and GOOP don't yet offer. In my opinion,
a few more OO features can be added to LV to allow for
even larger projects in the future provided they are used
well.

Earlier posts pointed out that C++ doesn't guarantee that
a project will succeed. OO features are just another tool,
and the tool can be misused leading to a failed project.
This is true to LV, C, C++, and all other engineering tools.
The key is using the tools at hand to best solve the
problems we face. Not glorifying or blaming the tools for
the state of the project.

> 3- Is LV going to stay "dataflow" or is it going to become OO?

LV is dataflow to the core. The definition of what data
is flowing may be expanded, but it will still be data
flowing down wires from one node to another that accounts
for how the program executes.

One of the limitations of the current GOOP is that all
objects are dealt with by a reference. By adding
language features, objects could be made to flow down
the wire, just like strings and arrays, meaning that
branching a wire doesn't lead to side-effects,
and there is no need to dispose objects.

> 4- What would be the great benefits of turning LV to OO that we don't
> already have with the dataflow approach?

Remember when LV didn't have typedefs? It was easy for
a cluster datatype to change once a project was underway.
That usually led to lots of edits on other panels to get
them back in synch. Without the unbundle by name, you
then went through the diagrams fixing all of the bundlers
and unbundlers to have the right number of terminals.
Changing the order of the cluster was even worse since
the diagrams may not bread, they might just access the
wrong field instead.

In many respects, an object is just another step along the
same path. An object is a typedef that can have code
associated with it for access -- maybe like Array and
Cluster Tools. Some of the typedef contents might be
publicly accessable, like now, while other elements are
hidden, only available to the implementation of the
typedef. That would force the user to use your functions
to manipulate things rather than hacking away at the
typedef contents. As an example, a LV string is really
just a cluster of size and characters. Since the diagram
can only modify the string using the string functions, you
never get the size and characters out of synch. That is
until you take it into LV generated code, a DLL or CIN
where you have access to the inner fields.

A related problem is that current typedefs are transparent
to built-in LV functions. If your typedef is just some
numbers, LV will be happy to perform arithmetic on your
typedef. Maybe this is what you want, but if this doesn't
make sense on your typedef, then your left with adding a
Boolean or a string so that the arithmetic isn't allowed.
Ideally, you would be able to state that = makes sense, >
and < don't, + and - only operates on the first numeric, and
* is something that you implement yourself. There would be
some safeguards so that the user of your typedef, which
includes you, wouldn't accidentally mangle the typedef
contents.

These may not seem like much at first, but they allow for
much more abstraction and better encapsulation. Finally,
there is a technique called inheritance that allows for
similar objects to be acted on by common code in one
location, and by specific code in another location depending
on which type of object is actually there at runtime.
This of usually done today by switching out on some inner
tag and dealing with each type in its own diagram. This
works fine until projects get large and teams get large.
Inheritance is a different way of implementing the exact
same thing that usually works much better for bigger teams
and bigger projects.

> 5- My opinion is that trying to implement OO in LabVIEW, is like trying
> to

Is this a fill-in-the blank question? It is difficult today
because the LV language doesn't yet support OO very well.
Early C++ was implemented on top of C using just a bunch
of macros and the preprocessor to mangle the C++ back into
C so that it could be compiled and run. Debugging was
done on practically unreadable text that vaguely resembled
your original code. By comparison, GOOP actually looks
pretty good. It is written entirely on top of the current
LV language and makes clever use of things like datalog
refnums to make strict types.

Over time I think GOOP will mature, and like typedefs,
some users will come to rely on it in a big way.
Other users will hopefully not even notice that anything
changed. If their project grows in complexity and they
need another tool to manage things, it will be just
another feature that helps them to get useful things done.

Greg McKaskle