Jump to content

Selecting which child class to cast to.


Recommended Posts

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

Link to comment

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
Link to comment
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.

Link to comment

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
Link to comment

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.

Link to comment

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?

post-17905-0-21589600-1328409644_thumb.p

Children.zip

Link to comment

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

Edited by ShaunR
Link to comment

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.

post-17905-0-71318800-1328415462_thumb.p

The dynamic VIs look like this

post-17905-0-12095500-1328415509.png

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

post-17905-0-64309700-1328415787.png

Link to comment

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:

post-18176-0-06168300-1328432339.png

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

— James

Edited by drjdpowell
Link to comment

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!

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.