Sibling Mutation

[Norm Kirchner]

I must be missing something....I would have imagined this would be easier.

The long and short is that

I have a wire of child class that I want to change to a sibling class

while retaining the data from the parent class.

I know that I can extract the parent information and push it into a new instance of the child class

but that seems rather clunky and not the right way.

Any direction please?

[Aristos Queue]

QUOTE (Norm Kirchner @ Aug 1 2008, 03:46 PM)

I know that I can extract the parent information and push it into a new instance of the child class but that seems rather clunky and not the right way.

Nope, that's the way to do it. You create a method on the parent class that takes two parents as inputs and unbundles one and bundles the results into the other.

QUOTE

I must be missing something....I would have imagined this would be easier.

Why would you imagine this would be easier? What you've just asked for is something I've never seen anyone have to do in any OO program I've seen in any language. I strongly suspect that a change to your class architecture would negate the need for this. Generally, if you find yourself needing to do this, ask yourself whether instead of inheritance you should be using containment instead.

[Norm Kirchner]

It's a simple enough structure.

Let me lay out what I'm doing to see if this still makes sense.

I've made an XControl which provides a common interface to multiple similar instruments.

The data type of said control is of parent object

Once a specific instrument is chosen, the data of the xctl is set to the appropriate child

But if the instrument type is changed, I want to keep the parent data the same

So this kind of structure allows the common controls between instruments to remain in the parent portion of the object while losing the instrument specific data once the instrument is changed.

So although this may be different than what others may have done in the past, I think that's a good thing because that means I'm doing something new but I resist the notion that I'm doing something wrong.

Truly the instrument class is the most common type of class that I hear about in examples anyways. It just happens to be that I'm trying to link a configurable interface with the object.

thoughts?

EXTRA DETAILS::The cool concept is that the XControl w/ the common config controls has an extra button that calls up an advanced dialog that is dynamically dispatched based upon the child object type on the wire. Another cool thing is that I also dynamically dispatch a VI that sets the ranges and disabled states of the common controls based upon a preconfigured control that exists in each child class.

So in the end you end up w/a common set of controls that are dynamically configured based upon instrument, and yet still provides access to non-common instrument specific configuration items.

....it's my baby

[Aristos Queue]

QUOTE (Norm Kirchner @ Aug 1 2008, 11:21 PM)

The data type of said control is of parent object

Once a specific instrument is chosen, the data of the xctl is set to the appropriate child

But if the instrument type is changed, I want to keep the parent data the same

How about this: Give Parent.lvclass a member of type "SpecificDetails.lvclass". When the XControl selects the type, you set the appropriate child of SpecificDetails.lvclass into the Parent object.

Assigning whole objects always works better than assigning parts of them.

PS: Is not that you're doing something "wrong" in the "this is bad programming and if the LAVA Code Repository had standards for LVclasses you'd be rejected". This is "wrong" in the sense of "it works but 9 out of 10 applications will expand to the point that they wish they'd picked an alternate architecture." But you might be that 10th architecture, so if it works, keep going. :-)

[Norm Kirchner]

Ok, I get what you're saying but what does the encapsulation give me or resolve (not being skeptical, just curious at this point)

so that if I am one of the 90% I can determine what is the weakness in how I'm architecting it.