>I disagree with your conclusion. This design is fine with me.

Of course, since you're used to it. But a design that destroys data after a benign change is a bad design. Imagine if we programmed our apps this way?

>Only the class to which the method was added knows about the existance of that method.

If the subclass has overriding method code in it, then it also knows about the existence of that method.

> If you change the name of that method in the class to which it was added, you take the responisiblity for all of the sub-classes and their dependence on that method.

That doesn't bother me. I'm of course aware that if I change the name of any identifier, I have to track down and change all references to it. However, that's not possible here (without hacking the VCX).

>The child class NEVER had that method in it. The method was in the parent class and you changed it there, the child simply inherited from its parent. When the parent no longer has a method named Foo, then the child class no longer has a method named Foo also.

Are you sure we're on the same page, Jim? The child class does indeed have code in it that's identified as overriding a parent class method of a given name.