Maintaining LVOOP type in a non-dynamic dispatch VI of another class

[Ben]

No problem Shane.

Even though I work in a shop with seven CLA's, their eyes glaze over when I start talking LVOOP in our tech meetings.

I think Yair has had to correct my memory on the quote;

"As face answers to face, and iron answers to iron, so does a man trieth words."

BTW: If you could post a small demo, I'll try to understand what it was you just said.

Ben

[Intaris]

I'll post an example tomorrow.

I remembered I have all my code on an SCC server, so I just downloaded it on my Laptop and checked things out.

I'll get some example code together tomorrow.

Shane.

[tst]

Sorry Ben, I think you made that one up. At least that's what it looks like from a Google search. I think the one you're thinking about is (and this is a bad literal translation) "Iron and iron together, and a man together with his friend", which uses the same word presumably to draw a comparison between sharpening the blade and your skill by using another person. Just be sure not to mix your metaphors and end up sharpening your iron on your friend, as that could turn out nasty. 😉
I believe you're also mixing it with the verse that comes two verses later - "As in water a face to face, so the heart of man to man" which (when translated into normal English) seems to mean "As in water face reflects face, So the heart of man reflects man".

I can't say I knew these and they're not what I would consider the greatest verses in the bible, but I'm not a fan of poetry (which this basically is). Even that chapter has things like "Faithful are the wounds of a friend" or "Better is a neighbor who is near than a brother far away" to name a couple which are better (IMO) and would be mildly popular (at least in Hebrew) and the book of Proverbs in general, by its nature, has quite a few proverbs which made it into common usage.

P.S. Shane, I know how you feel, trust me, although I can say I have at least one other guy who understands stuff quickly.

Message Edited by tst on 03.09.2009 11:41 PM

[Intaris]

Here's a Example I put together.

I have made the whole thing a bit closer to my actual use-case.

Class B is the communication Packet class.  I have defined a "String" data element for Read and Write.

Class B1 is a Child of B.  As such it has the Read/Write for "String" but also a new Read/Write for "Sub-String" which is some instance-specific piece of information which we need when coding.

I have then defined two Communication classes (The classes don't actually DO anything here) which accept an Object of Class B as an input.  The idea is that we can then Read/Write to "String" within the Communications class and then upon output, we can access the instance-specific information.  The "Sub-String" element of Class B1 is an example of this.

Class A defines the VI which accepts the object of Class B as DD with the terminals for Class A defining the DD behaviour.  As such, the DD is "foreign" to Class B.  This seems to be the important point.

Class A1 is an Override of this VI which makes a slightly different change to the Class B.

Class C is identical in function to Class A except for one thing.  We still have differences between the interaction with Class B but here we have shifted the DD boundary so that the Class B no longer has to actually cross this "foreign" DD boundary.  Please see the diagrams to see what I'm getting at.

-Observation-

When we use an object of true class B, we have no problems because we have no coercion (Types are the same throughout).

When we want to usea Class B1, we see a coercion to a Class B Object when using Class A as our Communications Class.  With Class C as our communications class (with the same functionality) we do not.

The result is that the output of the VI from Class A requires a "retain Run-Time Class" primitive to allow us to get access to the B1-specific properties whereas Class C does not.  Needless to say, the version with Class C is far more derirable.

Please note that the ACTUAL object class is not being modified, only the APPARENT class being carried on the wire.

I hope to have cleared up things a bit with this.  I find this behaviour interesting and think the Compiler is doing quite a good job of retaining Object types when possible.  It's nearly enough for a Nugget.....

Shane.

Message Edited by Intaris on 09-04-2009 02:59 AM

[Intaris]

I have successfully refactored my own code so that I no longer need to use the "Retain Run-Time Class" primitive to do what I want.

I learned something new today.... (Yesterday actually...)

Shane.