Jacemdom Posted October 10, 2006 Report Share Posted October 10, 2006 In response to this The need for lock in get-modify-set pass Naturally I cannot share my or rather our work projects at this forum. Is there anyone that would share a project where by ref OO is required to solve a problem efficiently in a simple way, so that i can see from my own eyes that this is really something missing in LabVIEW? jacemdom@videotron.ca Quote Link to comment
robijn Posted October 10, 2006 Report Share Posted October 10, 2006 In response to this The need for lock in get-modify-set passIs there anyone that would share a project where by ref OO is required to solve a problem efficiently in a simple way, so that i can see from my own eyes that this is really something missing in LabVIEW? jacemdom@videotron.ca For loadable drivers, complex measurement configurations, complex result storage. Parser building, file synchronisation (building up a tree of files), representations of various DUTs, representation of (different) products produced by a machine... I think if you don't know what you are missing then you don't miss it. You don't seem to have a need to work object orientated. That's fine. LabVIEW does not force you and will never do so. Read a good book about the subject and maybe you will find places where it can be useful in your projects. You are trying to find out why we don't want back, while you should try to find out why you may want to try to design object orientated yourself. I don't say you have to, but speaking for myself, the topics you raise are passed points. It seems like you're defending NI, something for which there is no need, NI can do that itself. I further don't think you would be convinced by a project. OO is a way of thinking. You can live without but once you're hooked... Joris Quote Link to comment
Mike Ashe Posted October 10, 2006 Report Share Posted October 10, 2006 I further don't think you would be convinced by a project. OO is a way of thinking. You can live without but once you're hooked... Agreed, just as LabVIEW and dataflow are a way of thinking. It is pretty easy to see where someone has thought in "C" in their head and then translated into LabVIEW. I suppose the same is true for OO-LV vs non-OO LabVIEW style. I'm still making the conversion myself, having been rather set in my ways after 15 years with the language. (I have a long delayed pet project that is being rebuilt in OO now, it's just a lot of work). That all being said, I think it is important to retain the ability to NOT program in OO once that is your dominant style. Using OO-LV or C++ to write "Hello World" projects is overkill. On large projects, with significant lifecycles it is invaluable. Quote Link to comment
robijn Posted October 10, 2006 Report Share Posted October 10, 2006 Agreed, just as LabVIEW and dataflow are a way of thinking. It is pretty easy to see where someone has thought in "C" in their head and then translated into LabVIEW. I suppose the same is true for OO-LV vs non-OO LabVIEW style. I'm still making the conversion myself, having been rather set in my ways after 15 years with the language. (I have a long delayed pet project that is being rebuilt in OO now, it's just a lot of work). Hi Mike, Can you maybe tell a bit about how you do the OO part of it ? LV's native OO or other ? What were the considerations for that decision ? Joris Quote Link to comment
Mike Ashe Posted October 11, 2006 Report Share Posted October 11, 2006 Can you maybe tell a bit about how you do the OO part of it ? LV's native OO or other ? What were the considerations for that decision ? Hmm, without spilling too many beans, let me say that I am actually tryng to do the same thing in more than one OO implementation. I am using the Open Source GOOP Template, the dqGOOP and possibly one onther. My reason is to find the optimum implementation for long term development of the project. I also am experiementing with a sort of pie-in-the-sky ideal of being able to use different implementations of GOOP in the same framework and have them act as interchangable plugin layers. It turns out that the different GOOP implementations are not all equal (obviously) and their are rather large speed and efficiency differences. As I said above, I am still making the transition myself, and there are several others here on LAVA that have a lot more experience with GOOP's than I do. I am not currently using the new NI built in gOOP at all, and probably will not for the forseeable future. First of all, I'd like to have backward compatibility as far as possible. Secondly it is new, and as much as I love LabVIEW and the NI team I have to say that most of the nifty new features or products are NRFPT in the first couple of versions. Perhaps I'll look at the new NI stuff in LabVIEW 9.x or 10 ... As to how, what, I am looking at objects being open files, internal data structures, GUIs, ... don't really want to get into more project specifics just now, sorry. Quote Link to comment
robijn Posted October 11, 2006 Report Share Posted October 11, 2006 As to how, what, I am looking at objects being open files, internal data structures, GUIs, ... don't really want to get into more project specifics just now, sorry. It was just sufficient. :thumbup: 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.