17 replies to this topic

[SteveChandler]

Hopefully the image explains my question pretty well. Can anyone tell me why this doesn't work? What is the correct way to determine which child to cast to based on an external index selection? Do I really need a case structure with the child class constant and a to more specific class for each child?

[drjdpowell]

SteveChandler, on 04 February 2012 - 07:20 PM, said:

Hopefully the image explains my question pretty well.

Not really, I’m afraid.

The “too more specific class” function only affects the wire types. Your saying “stuff the object on this parent wire into this child wire, if possible”. But though your selector returns a child object, that’s at runtime, not edit time, where the wire type out of the index array can only be the parent wire. So “too more specific class” isn’t doing anything here.

Does that help? I can’t actually tell what you want to happen. Actually, what are you using to get the name of the class in your subVI? Is that what isn’t working?

— James

[ShaunR]

SteveChandler, on 04 February 2012 - 07:20 PM, said:

Hopefully the image explains my question pretty well. Can anyone tell me why this doesn't work?

Arrays have to be of a single type. The child classes get coerced to the parent since that is the only type for which they are all compatable to exist as a single type within the array (and why you have coercion dots).
If you think about adding a Uint32 to a DBL array, the Uint gets coerced to a DBL right? So do your classes.

Edited by ShaunR, 04 February 2012 - 08:08 PM.

[drjdpowell]

The difference between objects and wire data types, and the different possible meanings of “coercion”, can be rather confusing.

[SteveChandler]

Thanks both of you. I think I understand.

drjdpowell, I am just wiring a constant to the write accessor. All the children look like this



I want to select a dynamic VI to execute and modify the parent data based on an index value.

[jgcode]

ShaunR, on 04 February 2012 - 08:04 PM, said:

Arrays have to be of a single type. The child classes get coerced to the parent since that is the only type for which they are all compatable to exist as a single type within the array (and why you have coercion dots).

That's not exactly true in this case, yes there is a coercion dot but what you now have in run time polymorphism whereby the 'wire' is an array of Parent by the data in that array is still a mixture of Child classes.

I don't see the need for the upcast (does it generate an error when it runs?) as you can wire the output straight into the Parent methods and the Child classes and any DD methods of the children will run.

If you wanted to use any specific (static) child methods then yes, you would have to convert the Parent 'wire' to the Child.

You should check out the Factory Pattern.

[ShaunR]

jgcode, on 04 February 2012 - 08:38 PM, said:

That's not exactly true in this case, yes there is a coercion dot but what you now have in run time polymorphism whereby the 'wire' is an array of Parent by the data in that array is still a mixture of Child classes.

I don't see the need for the upcast (does it generate an error when it runs?) as you can wire the output straight into the Parent methods and the Child classes and any DD methods of the children will run.

If you wanted to use any specific (static) child methods then yes, you would have to convert the Parent 'wire' to the Child.

You should check out the Factory Pattern.

Indeed. That is why the To More Specific "casts" it to the parent type (because that is what the type is on the wire, coerced by the array concatenation). The only way you can "extract" the contained class (as you point out) is via the invisible selection methods in the LVOOP system (the equivelent in my analogy of "extracting" the bits).

Edited by ShaunR, 04 February 2012 - 09:12 PM.

[drjdpowell]

SteveChandler, on 04 February 2012 - 08:25 PM, said:

I want to select a dynamic VI to execute and modify the parent data based on an index value.

Still not understanding. The dynamic VI to execute is determined by the class of the object passed along the wire. It almost looks like you are trying to change the class of the object coming in through the “Parent.lvclass” control terminal. Or that you want to be able to call the VI for ClassA on an object of Parent Class. One can’t do either off those things.

[SteveChandler]

I have a class with some attributes. Based on an external integer input I want to execute an algorithm to manipulate the attributes. In the simple example the parent class has a string as it's private data. If the external input is a 0 I want a dynamic VI to store 'Child A' in the private data, 1 stores 'Child B', and 2 stores 'Child C'. The dynamic VIs take no inputs as shown.

I got it working. I had the target and reference reversed! I attached the project. Is this the best way to accomplish this type of thing?

Attached File(s)

•  Children.zip (63.73K)
  Number of downloads: 6

[ShaunR]

I think most of our confusion (well, mine at least) arises from the fact you are trying to cast at all. I thought you were questioning why you get the parent after the cast rather than a child of the type you select.

What is wrong with

 Children_No_cast.zip (71.46K)
Number of downloads: 5

Edited by ShaunR, 05 February 2012 - 03:13 AM.

[jgcode]

ShaunR, on 05 February 2012 - 02:59 AM, said:

I think most of our confusion (well, mine at least)...

I mentioned that above too.

Steve - is there a specific reason you need/want to cast?

[SteveChandler]

Because I need to keep the state of the parent for each call to the dynamic VIs. Something similar to this:

Attached thumbnail(s)

• 

[SteveChandler]

I think that I might take a different approach. The above obviously doesn't work.

[Edit: I just saw jgcodes post New LVOOP Design Pattern KB. Is what I am doing below considered the Command Pattern?]

What I am thinking is to separate the parent from the children. What used to be the parent in my example will not have any children. Instead I will create another "execution" class that Child A, Child B and Child C inherit from. They will have a dynamic exec.vi that takes the class that used to be the parent as their input. These dynamic VIs will modify the data in that class through it's accessors. I know what I am trying to do is not unique and there is probably a design pattern for this.




The dynamic VIs look like this




And just for reference here is the "Get Type" VI in the first image.

Attached thumbnail(s)

• 

[ShaunR]

So you want a singleton?

[drjdpowell]

SteveChandler, on 05 February 2012 - 04:23 AM, said:

Is what I am doing below considered the Command Pattern?

Ah yes, this makes a lot more sense. It does appear to be the command pattern. Call your “execution” class “Command for <name of class command is for>” and your “children” “Command A”, etc. Your dynamic VI dispatches off of the Command child class, but the actual work is done with methods of the class the command is for. Here is a command-pattern execute method of mine, looking very similar to yours:



Note, btw, that one can put needed parameters inside the command object, such as the “Message” in my example.

— James

Edited by drjdpowell, 05 February 2012 - 09:00 AM.

[jgcode]

SteveChandler, on 05 February 2012 - 03:19 AM, said:

Because I need to keep the state of the parent for each call to the dynamic VIs. Something similar to this:

My reason for asking that question was to elicit such a response.
I am glad you have been able to sort it out using the a Design Pattern.

If you do anything cool - please share!

[SteveChandler]

Thanks everybody. I think I have read about the command pattern in the past but never fully understood it. The parts that I did understand must have been stuck somewhere in back of my head because I ended up implementing it.

The mini LVOOP Design Pattern KB is awesome! I have never seen those three patterns summed up so concisely like this.

jgcode, I am working on something that might end up being cool if I am successful, but mostly I am working on improving my skills. If I ever do anything cool I will definitely share it.

[jgcode]

Sweet!