Use of In place Structure outside a LabVIEW Class

[Naity]

This thread is a follow up to the point discussed in another thread. I opened a new thread to avoid polluting the previous thread with a second discussion. The link is http://lavag.org/topic/16669-universal-fgv/?p=103311 and I want to react to a message from JohnMc86:
 

I would suggest it is not as black and white as that. If you are trying to guarantee the correct use of the object in a reference design that is correct.

However I have used designs where I still make the methods take the object directly and the application is in charge of dealing with the DVRs. There are a few advantages:

• [*]The class is more reusable, it can be used by value or by reference. [*]DVR is a form of communication, the application architecture should and can dictate the communication method, not the library. [*]You can decide what functions are 'atomic operations' i.e. you have methods A, B, C. If each method passes a reference to another and you have two loops you could have the execution order A1,A2,B1,B2,C1,C3 or any other combination. If the methods pass objects you can wrap all 3 inside a in place element to guarantee A1,B1,C1,A2,B2,C2 or 2 then 1
  

Hi,

I get the advantage of working with both DVR and Objects. However I am still very sceptical about the use of the in place structure to read the object directly in the main VI. I see the DVR Based Objects a really safe way to work with class while making sure they are initialized and to avoid data copies. Working with In Place on the main VI theoriticaly gives me the right to remove an initialized object from a reference and replace it with another object from the class or, even worse, a non initialized object.

 

I am really sceptical on the "well coding" of this based on that point and also based on the fact that you are then manipulating an object outside a method.

 

Is it really the best way to go? Would it not be prefearable to write this function in a method (like "Copy Object" where the object in the reference is duplicated and both object and reference are output. Or a "To Object" and "To Reference" Method  with some error handling algorithm to make sure the object input of the "To Reference" method has correctly been initiated or is the same instance than the one that has been called from the "To Object" method)?

 

I ma still "new" to the GOO world, so there might be some subtlety I do not see.

 

Cheers

[Naity]

After testing, it seems like the LabVIEW Compiler does not allow to change a class instance inside a DVR. I wanted to try my 2 ideas experimenting 2 new design pattern (the "David Copperfield Design Pattern" which makes object disappear and the "Nicolas Flamel Design Pattern" to change lead into gold). I did not try the Nicola Flamel one but the compiler refuses the Davbid Copperfield one:

So I suppose my point of the previous post is partially invalid.

Still, I am skeptical on the fact of using the in Place Structure outside the class methods. What speaks again coding a method which copies the the current DVR Object into a normal object?

Thanks

Edited June 2, 2013 by Naity

[todd]

I get the impression that most people who use by-ref classes use IPEs inside the class' methods or inside a "class API".

Sometimes, they need more flexibility.

http://lavag.org/topic/16354-understanding-preserve-run-time-class-in-an-in-place-element-structure/

[drjdpowell]

JamesMc86 is suggesting the possibility of writing a by-val class and allowing the application level to decide on DVR use (or not).  The other options are writing a class API that takes DVRs as you’re doing, or use DVRs internal to the class (as todd mentions).  If one is doing a class API that takes DVRs, then I agree you probably want to restrict use of the IPE to within that API.  

[Aristos Queue]

What speaks again coding a method which copies the the current DVR Object into a normal object?

What is a DVR object? What is a normal object? These are not terms I understand.

 

There are objects -- they are the values of a data type that happens to get the name "class", no different than values of a integer or a string or a path or a waveform or a timestamp.

 

There are DVRs which create a reference to data -- any data, including objects, integers, waveforms or timestamps. Objects don't becomes some other type of thing merely by being held in a DVR, any more than they become a different type of thing when held in a Global VI or a queue or any other data storage.

 

There are a number of ways of packaging the DVR inside or outside the class, and it sounds like you're interested in the outside-the-class version.

 

I *think* you are asking, "In this model, what prohibits someone from opening up the DVR and copying the object to some other location?" Answer? Nothing. It's a by-value object and it can be copied freely. There's nothing the copier can do with the object other than call the methods on the class, so unless you've stashed more references inside the object, there's no worries. If you've stashed more references inside the object and you're worried about structured access to them, then you probably need to look at an inside-the-class model for by reference.

[JackDunaway]

...but the compiler refuses the Davbid Copperfield one:

 

Coming from a different angle, I have some ideas on how to take some magic away from the original design:

 

 

[JamesMc86]

I get the advantage of working with both DVR and Objects. However I am still very sceptical about the use of the in place structure to read the object directly in the main VI. I see the DVR Based Objects a really safe way to work with class while making sure they are initialized and to avoid data copies. Working with In Place on the main VI theoriticaly gives me the right to remove an initialized object from a reference and replace it with another object from the class or, even worse, a non initialized object.

 

I agree, in cases where a class must have initialisation forced this is a good method to protect it and there certainly are use cases for it. But for me LabVIEW is a dataflow language and OO doesn't have to break that.

 

Reference based APIs are great where you have to guarantee initialisation and protect access. There are also somethings that may suit it well, take a look at the extensible session framework (ESF) on ni.com for this. I also agree if you are using a reference based API it makes sense to force the IPE to not be allowed outside.

 

However if this is not absolutely require by the object then I see no reason to use it. It them becomes a matter for the architectural design rather than the object design how to move that data around and I believe you should provide a by value (dataflow compliant) API to fit with LabVIEWs cases and it is up to the developer how to use it.

 

My argument is not that it is a bad idea, but that there are better solutions for other cases.