Jump to content

From here on out, I'm using OO....


Recommended Posts

I swear I've done more templating and cutting and pasting in the past 3 days than I have in the past 6 months.

How many times did I have to create a VI identical to 10 others, except for which data in the clustosaurus it unbundles...

How many times did I need to change something "for the last time" in those ten VIs,and change every one of them subsequently...

How many times did I think, ooooh what if could inheritance to change just change the parent class instead...

When I was in high school learned OO concepts in C++ in computer science class, and wondered "what's the point of all this "inheritance" crap? Wouldn't it be easier to just ...." and promptly forgot all of it. Oh the callowness of youth :lol: !!! .

Link to comment
:D At least you already learned it, in a more classical sense. It's usually quite a task to "get" OO when you've only been working with (relatively) strict dataflow most of your life. I remember the simultaneous look of wonderment, confusion and disgust on my students' faces when I used to teach the Endevo GOOP course.
Link to comment

:D At least you already learned it, in a more classical sense. It's usually quite a task to "get" OO when you've only been working with (relatively) strict dataflow most of your life. I remember the simultaneous look of wonderment, confusion and disgust on my students' faces when I used to teach the Endevo GOOP course.

I wasn't aware that inheritance per se was "anti-dataflow". I do understand that byref implementations could be seen that way in certain use cases, or as an overall model for organizing OO within a dataflow environment/language, by I really don't get how byval implementations inherently are anti-dataflow.

Am I missing something?

Link to comment

I remember the simultaneous look of wonderment, confusion and disgust on my students' faces when I used to teach the Endevo GOOP course.

Chris, you looked a bit confused the first couple of hours when I taught you the course 10 years ago.

Now it's of course Symbio's GOOP course, and we're about to release a new version of GOOP Development Suite any day now.

Anti-Flow

Is Reference Objects, Anti-flow?

I guess it is, but it's also how you use it, this picture below is a reference singleton class that I call in a data flow sequence.

post-941-0-92415400-1327959448.png

Should you try to avoid Anti-flow?

Good luck and try.

All very simple applications could be done in pure Data-Flow, but as soon as you use any advanced features such as: File-IO, DaqMX, Vision, Queues, Semaphores, DVRs, Instrument References you are using references.

In my opinion, if you are an advanced user and ready for classes in LabVIEW, you already know the difference between Data-Flow and By Reference, and you know when to use the different techniques.

Cheers,

Mike

Link to comment

Chris, you looked a bit confused the first couple of hours when I taught you the course 10 years ago.

Now it's of course Symbio's GOOP course, and we're about to release a new version of GOOP Development Suite any day now.

Anti-Flow

Is Reference Objects, Anti-flow?

I guess it is, but it's also how you use it, this picture below is a reference singleton class that I call in a data flow sequence.

post-941-0-92415400-1327959448.png

Should you try to avoid Anti-flow?

Good luck and try.

All very simple applications could be done in pure Data-Flow, but as soon as you use any advanced features such as: File-IO, DaqMX, Vision, Queues, Semaphores, DVRs, Instrument References you are using references.

In my opinion, if you are an advanced user and ready for classes in LabVIEW, you already know the difference between Data-Flow and By Reference, and you know when to use the different techniques.

Cheers,

Mike

Mike,

I think your doing a pretty pure virtual call here using setmp()....

The issue isn't about whether or not to use references. It's about whether OO implementations are natively byref or byval.

One COULD say that all of the text that everyone sees using a traditional C++ really are references to constructs in assembly, based on compiler called in the build process. Similarly one COULD also say that all of the graphics that are seen when using LV are also references to, ultimately, the same underlying constructs in assembly. But none of that is really the point is it?

Link to comment
All very simple applications could be done in pure Data-Flow, but as soon as you use any advanced features such as: File-IO, DaqMX, Vision, Queues, Semaphores, DVRs, Instrument References you are using references.

Only because our hardware APIs are so poorly designed as to require references. The world doesn't have to work that way, but by historical precedent it does.

Link to comment

Only because our hardware APIs are so poorly designed as to require references. The world doesn't have to work that way, but by historical precedent it does.

Too bad you weren't involved in the FileIO/driver design from the start, then LV might have been a pure data Flow language.

But maybe we need to start with a Pure DataFlow operating system to get it working properly.

Link to comment
Too bad you weren't involved in the FileIO/driver design from the start, then LV might have been a pure data Flow language.

But maybe we need to start with a Pure DataFlow operating system to get it working properly.

Nope. There are other languages -- I have worked with both Haskell and Lisp, but there are others -- that are reference-free on existing operating systems.
Link to comment
Chris, you looked a bit confused the first couple of hours when I taught you the course 10 years ago.

Ha! I can't argue with that :D

In my opinion, if you are an advanced user and ready for classes in LabVIEW, you already know the difference between Data-Flow and By Reference, and you know when to use the different techniques.

Right - and, in my opinion, one hurdle that's relatively easy to overcome, yet trips up so many people, is nomenclature. Classes, objects, encapsulation, inhereitance, methods, properties, singletons, etc <- these words might be forgien to someone starting to work with OO, but they're usually just names of something they already know (and have probably even used!), but it's just takes some time to get your mind around them.

  • Like 1
Link to comment

Nope. There are other languages -- I have worked with both Haskell and Lisp, but there are others -- that are reference-free on existing operating systems.

Right, some folks are either pretty young (who remembers FORTRAN and PL/1?) or not as well exposed to alternate platforms. Personally I'm glad to be out of assembly limbo as well as the next couple of rungs up towards the Paradisio...

Even Ken didn't keep the original Unix releases as pure as some thought. There are some realities in terms of time and resources that ultimately constrain real-world development. Seems like some academics never quite get that -- but I do definitely respect their idealism and commitment.

Link to comment
  • 2 weeks later...

Mr. Manners I'd just like to reanimate this thread to second your commitment to learning how to LVOOP. I've just spent the last week adjusting and readjusting plugin type VIs over and over, having to manually implement the same changes across each VI every time I uncovered a new bug in my implementations. Ugghh, now if only I could wrap my head around how to think about the launch methods for classes and equate that with running Sub-VIs programmatically, I think I'll be able to crack something important!

I need to set aside some time to sit down and try and DO, not just scratch my head over what's possible and not possible. If only I had more time!

Link to comment

I need to set aside some time to sit down and try and DO, not just scratch my head over what's possible and not possible.

Yep, OOP is very much a learn-by-doing skill, not a learn-by-thinking skill. I can't count the number of times I've thought something would work only to discover during implementation that it doesn't quite do what I thought it would.

If only I had more time!

Any chance you can start incorporating it into your every day job?

(FYI, I've spent *many* nights and weekends in front of the computer implementing different ideas to see how they worked out.)

Link to comment

Hey Daklu,

Yeah it is probably possible. Right now I'm sipping my morning coffee and going over your Slave Loops concept. I feel that it's probably very similar to what I'm trying to do with my code but implemented in an OOP sense. Hopefully I can draw some parallels and a light will click. I'm particularly interested in the idea of launching and shutting down a slave process as needed.

I've gone through a really torturous route of wrapping each process inside a message handler framework, with an FGV pertinent to each process which is solely responsible for passing the stop message from the message handler to its process. The "process-nested-inside-message-handler" is in turn launced by a master message handler which handles input from the user to determine what tests should take place. I just had a blinding realisation as I wrote this that I could have handled this much simpler with a 0 time out queue in each process that listened for a stop message and if timed out did whatever the process was trying to do. One of the key assumptions that led me down my torturous path was that I must have a default case that handles messages which don't correspond to real messages. *Realisation* In fact, I could just use the timeout line on the queue to nest another case structure and still handle the default (incorrect message) case, gah, so much time wasted.

From looking at your slave loops template posted in this thread, am I right in assuming that if you wanted a different slave behaviour (a new plug in if you will), that you would merely make a new execute method in the SlaveLoop class? Or would you instantiate a whole new child class of SlaveLoop.lvclass with its own execute method?

Following on from my confession of my own wrangling efforts, how would you formulate one of your slave loops that needed to be a continuous process but also accept stop commands, would you use the timeout method I thought of above, or something else?

What would you do if you wanted to be able to close and reopen your slave loop without locking your code up? What I'm getting at here is, what is the OOP equivalent to launching a sub-vi using a property node with "Wait Until Done" set false?

Thank you for the opportunity to pick your brains! Your posts are always amazingly informative, even if it does take me months for things to finally click into place...

Edited by AlexA
Link to comment

I feel your pain Alex. I need to sit down and DO as well. I'll probably never get time to implement anything OO on my current project, but hopefully my next gig will involve making a nice desktop VI from scratch and I can do it in an OO fashion right from the start. Meanwhile I'll do a CLD exercise or two using an OO framework, to give me something to do.

Link to comment

FYI for you guys, once you're comfortable working with LVOOP and ready to move to the next step, Head First Design Patterns is an excellent book for learning how to use OOP to do what you want.

(Warning: After reading it you'll want to use patterns everywhere you can. I did and I've seen posts from other hinting at the same thing. That's a great way to learn how to implement the patterns, their pros and cons, and how they apply to LV, but it will add time and complexity to your projects. I'm just sayin...)

Link to comment

Head First Design Patterns is an excellent book for learning how to use OOP to do what you want.

I like that book as well and recently bought my LV team a book each, the perfect valentines present :-)

post-941-0-45671500-1329631824_thumb.jpg

I have also implemented the Decorator Design pattern using referenced based objects with the DVR. (Symbio’s GOOP4).

DecoratorPattern.zip

You can read this design pattern here for free:

http://oreilly.com/catalog/hfdesignpat/chapter/ch03.pdf

Cheers,

Mike

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.