MarkCG Posted January 27, 2012 Report Share Posted January 27, 2012 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 !!! . Quote Link to comment
crelf Posted January 30, 2012 Report Share Posted January 30, 2012 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. Quote Link to comment
Val Brown Posted January 30, 2012 Report Share Posted January 30, 2012 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? Quote Link to comment
crelf Posted January 30, 2012 Report Share Posted January 30, 2012 Sorry, I can see how you read that, but I wasn't trying to say that OO is anti-dataflow, just that anything non-OO is, well, non-OO Quote Link to comment
Val Brown Posted January 30, 2012 Report Share Posted January 30, 2012 OK, just checking.... And I know that paradigm-shifting look of "My God. It's full of stars..." that shows up on students' faces when they really do see something in a completely new way. Quote Link to comment
crelf Posted January 30, 2012 Report Share Posted January 30, 2012 Oh yeah - it's soooo pretty to watch 1 Quote Link to comment
MikaelH Posted January 30, 2012 Report Share Posted January 30, 2012 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. 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 Quote Link to comment
Val Brown Posted January 31, 2012 Report Share Posted January 31, 2012 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. 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? Quote Link to comment
MarkCG Posted January 31, 2012 Author Report Share Posted January 31, 2012 *cue "Thus spake Zarathustra"* .... Floating in the void of cyberspace, I am reborn is the OOPChild !! Quote Link to comment
Aristos Queue Posted January 31, 2012 Report Share Posted January 31, 2012 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. Quote Link to comment
MikaelH Posted January 31, 2012 Report Share Posted January 31, 2012 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. Quote Link to comment
Aristos Queue Posted January 31, 2012 Report Share Posted January 31, 2012 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. Quote Link to comment
crelf Posted January 31, 2012 Report Share Posted January 31, 2012 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 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. 1 Quote Link to comment
Val Brown Posted January 31, 2012 Report Share Posted January 31, 2012 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. Quote Link to comment
AlexA Posted February 15, 2012 Report Share Posted February 15, 2012 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! Quote Link to comment
Daklu Posted February 15, 2012 Report Share Posted February 15, 2012 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.) Quote Link to comment
AlexA Posted February 15, 2012 Report Share Posted February 15, 2012 (edited) 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 February 15, 2012 by AlexA Quote Link to comment
Daklu Posted February 15, 2012 Report Share Posted February 15, 2012 Alex, I'm working on a response but would you mind reposting this in the slave loop thread? It will help when people search for information in the future. Quote Link to comment
AlexA Posted February 16, 2012 Report Share Posted February 16, 2012 Not at all, pasting now. Quote Link to comment
MarkCG Posted February 16, 2012 Author Report Share Posted February 16, 2012 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. Quote Link to comment
Daklu Posted February 18, 2012 Report Share Posted February 18, 2012 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...) Quote Link to comment
MikaelH Posted February 19, 2012 Report Share Posted February 19, 2012 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 :-) 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.