Anyone still using GOOP?

[bsvingen]

I suddenly discovered that I never use GOOP any more. Somehow LVOOP and queues seem to do the job better, with better consistency, less coding and with less clutter than any GOOP could ever do. LVOOP is also faster for some reason. The only by ref objects I have are made in C++, mostly due to complex algorithms not easely made in G, not due to by ref programming paradigm.

Anyone else experiencing this?

[Mark Yedinak]

We still have a bunch of dqGOOP stuff but we use it mainly because these objects are used so prevalently in our code base. I would prefer to rewrite them in LVGOOP but it seems we never have the time. The old adage of "if it isn't broke, don't mess with it" applies. Anything new that we do is done in LVGOOP.

[crelf]

Quick clarification before we get into this too deeply:

• LV-OOP = native by-val OOP built into LabVIEW 8.2 and above
  
• GOOP = Endevo by-ref OOP implementation
  
• dqGOOP = DataAct by-ref OOP implementation based on queues
  
• OpenGOOP = OpenG by-ref OOP implementation based on object repository
  
• ClassicOOP = (VISTA Class Generator) by-ref OOP implemenation based on object repository locked with semaphores (now defunct)
  

We now return you to your regularly-scheduled programme.

[Aristos Queue]

Quick addition to crelf's clarification:

QUOTE (crelf @ Feb 23 2009, 12:48 PM)

GOOP = Endevo by-ref OOP implementation

The latest edition of the "GOOP Toolkit" from Endevo is built out of LVOOP classes, and the toolkit includes tools for manipulating both GOOP classes and LVOOP classes.

We now return you to your irregularly-scheduled return to your regularly-scheduled programme.

[Val Brown]

QUOTE (bsvingen @ Feb 23 2009, 11:15 AM)

I suddenly discovered that I never use GOOP any more. Somehow LVOOP and queues seem to do the job better, with better consistency, less coding and with less clutter than any GOOP could ever do. LVOOP is also faster for some reason. The only by ref objects I have are made in C++, mostly due to complex algorithms not easely made in G, not due to by ref programming paradigm.

Anyone else experiencing this?

Are you saying that LVOOP "...and queues" covers the water front or am I misunderstanding you?

[bsvingen]

Well, yes – at least that is my experience. As long as I stick with AOP (Actor Oriented Programming) paradigm using LVOOP, sate machines and queues, I simply feel by ref GOOP will add nothing.

[crelf]

QUOTE (Aristos Queue @ Feb 23 2009, 04:33 PM)

Quick addition to crelf's clarification:

OOPs - you're right - sorry, I meant to mention that. I'll update the list.

[Val Brown]

QUOTE (bsvingen @ Feb 24 2009, 07:27 AM)

Well, yes – at least that is my experience. As long as I stick with AOP (Actor Oriented Programming) paradigm using LVOOP, sate machines and queues, I simply feel by ref GOOP will add nothing.

Can you -- or someone else here -- clarify what would be "missing" from such a stance: ie what does "by-ref" add at a functional level that is not available with what you're reporting. Not being "deep" in OOPs I'd really like to hear this laid out as clearly as possible by those who know.

Let me say this another way: if the native LVOOP really does "do it all" then I'm much more interested in pursuing OOP within LV. If not (yet?) then I might just wait to jump into the pool until the native implementation does "cover the waterfront". I don't want any "OOPs" or "gotchas" along with way.

[Grampa_of_Oliva_n_Eden]

QUOTE (Val Brown @ Feb 24 2009, 11:46 AM)

Can you -- or someone else here -- clarify what would be "missing" from such a stance: ie what does "by-ref" add at a functional level that is not available with what you're reporting. Not being "deep" in OOPs I'd really like to hear this laid out as clearly as possible by those who know.

Let me say this another way: if the native LVOOP really does "do it all" then I'm much more interested in pursuing OOP within LV. If not (yet?) then I might just wait to jump into the pool until the native implementation does "cover the waterfront". I don't want any "OOPs" or "gotchas" along with way.

I'll give it a try since I have not been OOPing long enough to fall into the trap of using those fancy OOPish terms.

I understand the difference is the nature of the wire being passed around. IN LVOOP the data is in the wire. The "by-ref" version passes a reference to the data.

So it is a question of where is the data. Since LVOOP is smart enough to work in-place it ends up being faster. The by-ref version requires moving the data (after getting a lock) to where it is manipulated and then putting it back. THe movement of data back and forth is what always kept me out of GOOP but the native LVOOP removed that limitaion.

THe only limitation that I ran into is something that is an automatic in my design but not straight forward in LVOOP. I understand it to be called an "Active Object". These are objects that once created can go on by themselves doing their job while also offering services (methods) to other objects.

Ben

[Val Brown]

QUOTE (neBulus @ Feb 24 2009, 09:59 AM)

I'll give it a try since I have not been OOPing long enough to fall into the trap of using those fancy OOPish terms.

I understand the difference is the nature of the wire being passed around. IN LVOOP the data is in the wire. The "by-ref" version passes a reference to the data.

So it is a question of where is the data. Since LVOOP is smart enough to work in-place it ends up being faster. The by-ref version requires moving the data (after getting a lock) to where it is manipulated and then putting it back. THe movement of data back and forth is what always kept me out of GOOP but the native LVOOP removed that limitaion.

THe only limitation that I ran into is something that is an automatic in my design but not straight forward in LVOOP. I understand it to be called an "Active Object". These are objects that once created can go on by themselves doing their job while also offering services (methods) to other objects.

Ben

Thanks for the explanation. You've hit on a couple of points that I've wondered about and thought I understood and it seems like I probably do because you've expressed the same understandings.

1. the "by-ref" implementations will, almost inevitably, execute more slowly for "equivalent" code. This is because of the multiple operations needed to "access" the data through the "by-ref" process.

2. This might be helpful from a design perspective -- esp for those used to by-ref object design -- but it will also lead to the likelihood of runtime penalties in performance.

3. There are work-arounds using by-val that can address the "limitations" of that approach re: point 2 above.

Do you an example of the "Active Object" code that could be uploaded here? I'd like to see how you've done it and then, if possible, get comments from others about it, esp from those who favor a "by-ref" approach.

All of that would really help me understanding this issue more deeply.

[bsvingen]

I just know by experience that my old programs using GOOP and call by ref vi's, simply get cleaner and "tighter" and more modular when using LVOOP and Actor principles (after getting familiar with actor oriented design). IMO LabVIEW is in many ways the "native programming language version" of Simulink or Ptolemy. Where Simulink and Ptolemy is built on top of some other languages to be Actor Oriented simulation environments, LabVIEW is sort of built from the ground to be an Actor Oriented visual programming language (I don't know if it actually is, but I pretend it is, and it works real good ). LabVIEW is also dataflow, but the main limitation with that is not the dataflow itself (call by value), but the implicit synchronizing and serialization caused by the wires (easy to work around but still a limitating factor), and none of the GOOPs changes any of that, they just change a data-wire for a ref-wire.

Anyway, I like to think like this. LabVIEW simulates instruments. It is in all respect a 100% configurable software version of a concurrent embedded system of processes that manipulates any kind of data in any way possible, a virtual instrument. Just like Simulink and Ptolemy can be used to simulate anything, so can LabVIEW. Simulink and Ptolemy forces you to think actor oriented rather than object oriented (in the traditional meaning) or procedural, because there is no other way. LV does not force you to to that, but if you do LV really shines and so do LVOOP. In this respect LVOOP is a completely new concept altogether, it is an object oriented version of actor oriented design. I am not sure if that is entirely correct, but it works for me much better than GOOP.

[GregSands]

Do you have a small code example you could post that shows how you structure things from an "Actor-oriented" point of view? I'm trying to work out how it is different to standard OOP in the practical case.

[Val Brown]

QUOTE (bsvingen @ Feb 24 2009, 12:57 PM)

I just know by experience that my old programs using GOOP and call by ref vi's, simply get cleaner and "tighter" and more modular when using LVOOP and Actor principles (after getting familiar with actor oriented design). IMO LabVIEW is in many ways the "native programming language version" of Simulink or http://ptolemy.eecs.berkeley.edu/' rel='nofollow' target="_blank">Ptolemy. Where Simulink and Ptolemy is built on top of some other languages to be Actor Oriented simulation environments, LabVIEW is sort of built from the ground to be an Actor Oriented visual programming language (I don't know if it actually is, but I pretend it is, and it works real good ). LabVIEW is also dataflow, but the main limitation with that is not the dataflow itself (call by value), but the implicit synchronizing and serialization caused by the wires (easy to work around but still a limitating factor), and none of the GOOPs changes any of that, they just change a data-wire for a ref-wire.

Anyway, I like to think like this. LabVIEW simulates instruments. It is in all respect a 100% configurable software version of a concurrent embedded system of processes that manipulates any kind of data in any way possible, a virtual instrument. Just like Simulink and Ptolemy can be used to simulate anything, so can LabVIEW. Simulink and Ptolemy forces you to think actor oriented rather than object oriented (in the traditional meaning) or procedural, because there is no other way. LV does not force you to to that, but if you do LV really shines and so do LVOOP. In this respect LVOOP is a completely new concept altogether, it is an object oriented version of actor oriented design. I am not sure if that is entirely correct, but it works for me much better than GOOP.

Thanks for the reply. That helps too.

Can you recommend a good book or other written resource for what you're calling "Actor Oriented Design"? I'd like something that you feel comfortable with, that was/is helpful to you, esp in facilitating seeing LV in the way you've described. And, of course, others here may have some good resources to suggest as well.

[Grampa_of_Oliva_n_Eden]

QUOTE (Val Brown @ Feb 24 2009, 01:20 PM)

...

Do you an example of the "Active Object" code that could be uploaded here? I'd like to see how you've done it and then, if possible, get comments from others about it, esp from those who favor a "by-ref" approach.

All of that would really help me understanding this issue more deeply.

No I don't have a demo just the complete application. Lets see if this helps. I wrote a "Controls on the Fly" app that when in run mode took this form.

http://lavag.org/old_files/monthly_02_2009/post-29-1235507532.png' target="_blank">

Picture was seperate process that kept a picture control updated on the GUI.

Object was one of a 100 widgets that could be dropped on the screen.

Information was an engine that interfaced to the real world or a simulator.

WHen a value changed, the correct instance of "Object" had to be updated.

When a user clicked on a region of the picture allocated for the "Object" Picture had to tell the correct "Object" about the click.

"Object" could decide to change itself (like a scrolling marque indicator).

So "Object" exposed methods that where avaiable to Picture and Information but could also do internal methods.

So where do I keep the data for an instance of "Object"? If I stuck it in Picture or Information then either one or the other would have to be interupted or invoked from the other. On top of that, to let the Object jiggle itself, then whoever owned the data would have to periodically touch the "Object" so it could do its thing.

So rather than slamming the Object into one or the other I made it its own loop so it update itself any time it wanted.

To expose the Methods "Mouse Move" "and "Update Value" the Object has a unique queue to accept the Method invokation. The LVOOP method a used by the Picture effectively queued up the Method requestod required a response, the queue had built into it, a response queue that the invoker could monitor for a message with the returned data.

So the Picture used the queue ref for that instance of Object to request the method.

This worked fine in my book with 100 indicators/controls updating at 10 Hz with only about 35% CPU usage.

What I did not like about the final app was that I could only crate about 100 widgets before I ran out of memory. I would have liked to have done more but the customer was happy so I never dug deep enough to see if I changed the structure a little if the foot-print for every instance would be smaller.*

Just trying to help and maybe learn something on the way,

Ben

* I have this suspicion that in one of my methods I was stashing away the entire screen instead of just the background of the Object. 100 copies of a huge monitor can fill memory fast.

[Val Brown]

QUOTE (neBulus @ Feb 24 2009, 01:34 PM)

No I don't have a demo just the complete application. Lets see if this helps. I wrote a "Controls on the Fly" app that when in run mode took this form.

<....>

Thanks, yes that helps and, at some point, if someone can, a "small" example would be very wonderful. They probably already exist so maybe someone here knows an example they can point to. Again what would really help me would an example that hews as close as possible to these descriptions.

And FWIW, this is a really great thread for me!

[bsvingen]

I think the best source is the Ptolemy web site, with tons of info. Here is a ppt file with some basic info. Ptolemy is open source, and the best way to study actor oriented design is to download and use Ptolemy, or at least look at some examples. Ptolemy is really super high quality stuff.

An actor is very simple. A LabVIEW vi is an actor by the definition of an actor. Data flows through it, and it has input and output ports as well as parameters and/or states (state machine). In contrast, no data flows through a GOOP/C++ object, a GOOP object has data that has to be initialized and methods that has to be invoked.

An LVOOP vi is like a super star (Marlon Brando ). It can take different kinds of data and do different things according to what data actually enters + lots of other usefull stuff (encapsulation, better modularity, less coding and so on).

An actor IS the machine firing up automatically when data enters, while a GOOP is a vague representation of what the machine can do with no concept of time, it has to be told to act.

[shoneill]

QUOTE (neBulus @ Feb 24 2009, 09:34 PM)

No I don't have a demo just the complete application. Lets see if this helps. I wrote a "Controls on the Fly" app that when in run mode took this form.

Sounds a lot like Components to me..... Objects interact based on their interfaces... (possibly) seperate run-time instances for each item.....

I like components but I don't see a clear distinction between them and "active objects".

Anyone?

Shane.