robijn

Do you think there's an obstacle for loading a .lvclass in LV10 ? Joris

Hmm you'respawning threads like labview spawns parallel processes... Should we first get more depth in the other ones ? I have some material left for the locking issue... No time right now though. Joris

Hey that's a very nice... uhm well summary is not the right word. The discussion is quite complex as this shows. Thanks for the effort. I think referencing objects do not give a real conflict with dataflow. You only need to realise that if you use them at multiple places you may get a problem. But I think LV should solve that with native locking, in whatever way. There's a separate thread for that. If this locking is done, there is hardly any difference left between a containing wire and a referencing wire. Then the locking mechanism instead of the dataflow mechanism will arrange the serialisation. A starter won't notice. Joris

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

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

A native referencing system allows to leave a lot of added weight out. You could consider it simpler actually. You would not need to notice that you are actually using a reference. Like in Java. A starter does not see the difference. He does not use the data in parallel at two different places. And if he does, he has a bigger problem with the current system than with a refencing system. Don't forget young programmers are all used to work with objects. If you tell them that LabVIEW may wait a while before you can execute a method until an other method running in parallel is completed, they may (should ) say: "Hey that's great, in C I had to write all that protection code myself." And this behaviour would be perfectly natural, just like a VI can only be executing once at a time. This document explains a lot. Something that I agree with it that keeping dataflow is important. The argument that it prevents problems when using data in parallel is oversimpling the situation by far and I think it's wrong. For me the document contains no argument against a referencing wire, only arguments for. I think that's what I'm doing in my job constantly. I create the generics (e.g. framework), others use them (And me myself too, BTW). It's needed because the complexity of a measurement system as a whole is often quite big. But the complexity in specific areas is not very big and other users can handle it there. There is so much stuff in common between the various tests that I only need to write the more complex generic stuff and enable the other users to write the specific code for their test without too much of a hassle. That's the nice thing about power users, they enable others to work with LabVIEW. Success with your exploration of OO in LV. Joris I really hope to see more NI designers in the discussion. So far I am quite disappointed by their presence. Stephen fiercely continues to defend his standpoint, which I can appreciate and respect. But it looks as if noone at NI actually thinks what so many of us power users think. Very strange. Maybe NI disallows discussing these issues outside the company, which I could partially understand. Joris

You could attach a probe to the wire and see what the object's attribute's values are... You could open a diagram and set a breakpoint. Maybe you could have a front panel and block diagram per instance of an object... In the diagram things don't look different at all. It's only the behaviour on life-start and life-end where things are different. The current systems creates a new object when you branch a wire, and removes an object from memory after the data in the wire is not used anymore (this is the simple version of the story ). A referencing system creates an object on request (allows to have a constructor) and removes it on request (allows for a destructor; may allow for automatic destruction when an object is not used anymore but this is tricky business). The fact that the programmer needs to request a new object prevents having "parallel universes" by accident. The "request to create" could in practise be the constructor placed on the block diagram, just like a method is placed now. Joris

Noone should force you to use OO. To use OO should never be a target on itself. All programs I'v written that use OO aspects don't do that everywhere, only for the parts that it's useful. But I don't think the usefulness of OO is something that should be discussed here. It's already in and it will never leave LabVIEW. And obviously you can build OO systems without native language support. "C with classes" was the first implementation in C, it was done only in #define's etcetera. I agree with you that's essential. I believe there is a lot of power in dataflow. The route of the data on the diagram tells so much. But dataflow only works locally, in a VI and towards its subVIs. For the app as a whole dataflow is not appearent. We use functional globals all the time (I hope you do as well!) to store more complicated things that need to be accessed from multiple places. A functional global does not follow the dataflow paradigm, as it stores data in shift registers. So at that point the dataflow ends (or starts). You can use dataflow up to the functional global, and even inside the functional global, but once you place that functional global in multiple VIs the dataflow is disturbed. The same modified data does not flow in and out, a lot of data may be stored inside the VI. Dataflow is a great concept, but there are limits to it. The trick is to go past the limits in the best way. A functional globals is a such way, the event structure - a fascinating solution by NI - is such a way and native referencing OO would be another. You mean you are affraid debugging is going to be more difficult ? Then NI should add features to make that possible. It is quite important to keep it "Rapid development". Joris

Yes that's what I meant as well. Immediate actions on the referenced object. Why retrieve and store it in the first place ? That was only necesary for GOOP, but not for NI ! The GOOP-ers could not access the stuff under the bonnet of LabVIEW, but NI can. The differences between the currently implemented static objects and referenced objects are very small. The diagram of a method would look the same. A big plus would be that there would be no object-set and object-get methods, or wrappers required. That's all just extra code that we need to carry around every time, which conflicts with a reason to go for OO: preventing code duplication. Having a referencing wire would allow for constructors and destructors. I completely agree with Jimi the current system is not true OO. The state of the object should always represent something in the real world and this is currently not enforcable. With con/destructors, if I would destroy an object of class IniFile, I could flush the file data and close the file nicely. Or for a driver you could free resources (eg. close a port). And on creation the state should be known as well. Generally speaking, you can keep things consistent. That is impossible now, the programmer can screw things up easily. If he branches a Keithley2000 wire and performs different operations on each object, the objects do not know of eachother and the state of the multimeter is incorrectly known. The language construction should prevent this to be possible. I hope NI changes its mind and changes the implementation to ref-wires in LV9. There would be no real problems with that, programs written in 8.20 would still work. On converting to 9.0 wire branches would be a problem, but it could be solved by inserting a copy constructor at that point. The class will need a copy constructor for that, but it could be added automatically on conversion. So the door is still open. Joris

What about this problem (which I mentioned in an other thread). Let's assume each method is derived from a template method and retrieves the object data at the beginning and stores it at the end. Now, if you have three methods: - refresh (stores timestamp of refresh in object, and calls the following 2 methods) - retrieve scope wave (reads wave from scope and stores it in object) - retrieve scope settings (reads scpe settings and stores them in object) would this mean that each method retrieves and then stores the data ? Rather inefficient. And there need to be an exception for the first method, because it should store the updated data before calling the others. Or read and store after calling the submethods... What do you think about this ? What have been your solutions on GOOP (and maybe other LV OO systems) ? Let me make this statement: A referencing OO system does not need a Retrieve-Modify-Store system where you retrieve all data and store all data. Joris

If you have wire level reentrancy you usually would not need recursion. You could then call methods of other objects which is usually what you want recursion for: traversing a tree etcetera. You only cannot revisit the current object. Joris

I think you're cutting a corner here. There is (AFAIK) one stateless VI type now, the subroutine. All others have at least some state, even reentrant VIs, and this state data has probably become more for methods. A VI that has no "used" frontpanel objects and no shift registers is almost stateless already, so why introduce a new type ? I am in favor of storing the VI state with objects, also for front panels. That is ideal for drivers. But it is useless to store VI states with objects if objects are cloned without you notice it, like they currently are. Really, make some examples for yourself and you will be convinced. It's only interesting if the object wire would behave like a native reference. Joris

No I was talking of a future native implementation by NI. The reference they would introduce, to what exactly would it point ? If it were to point to data in a shift register, then that data should be able to become altered without the VI that contains the shift register knows it. That means you would throw the encapsulation of a functional global out of the window. Bad...

Yeah right and get all the problems of C... No thanks. That's why you can't manually create a ref in Java. If you have an object (=ref) in Java then it is always poiting to an existing object (unless the reference is explicitely made NULL). Besides, in LV, what should the reference then point to, to an object in a shift register ? Which you can then silently modify without the "owner" knowing about it ? That's a can of worms. Well, don't we all have semaphores on our VIs that control parallel execution of the same VI ? We use this mechanism to make sure calls to functional globals (LV2 style globals) are serialized correctly and fairly. This shows it can be VERY efficient. Joris

Wire level reentrancy is nice but can only be practically implemented with referencing wires (unlike the current implementation). Otherwise you would need to clone all method dataspaces when the wire branches. Not to mention visible frontpanels... It would have been a fantastic feature. Joris

Hi everyone, I want to point out that any "retrieve - modify - store" system has a problem: when/where do you retrieve and store the data when calling an other method of the current class ? I see two possibilities. 1. You do that in a wrapper VI. This has the disadvantage that each method needs a wrapper VI, so you effectively double the number of VIs. Code replication. If you want to call a method of the current class you don't call the wrapper VI but the method VI directly, and you hand it the object data directly. 2. You do it in the method VI. Code replication over there. Before you call an other method of the current class you need to store the current object (if you have made any modifications) , bacause the other method retrieves the object again. Neither way supports calling two methods in parallel. Because they would not modify the same object but two different objects and on return of the methods, both data sets would be saved to the same object in the repository so one set of modifications would be lost. The way to prevent this would be a system that immediately stores any change into the object. Like you would handle an object in any other language. Much more intuitive, less prone to error and much much less code replication. Think outside the GOOP box ! Joris

Hi, I've tried to strip the VI smaller and keep the problem. It seems that the problem boils down to the type connected to Create Queue. The constant seems to be "corrupt". Modifying its type definition or changing it to a constant does not resolve this, but when you re-create it it's fixed. Joris Download File:post-1555-1141826795.vi Download File:post-1555-1141826825.ctl