>VB is laced with legacy issues that make it, quite simply, a monster. VB is far more "stable", in the negative sense, than FPW ever was (or could be). Also, in 1999, VB has dozens of times the installed base that FPW had in '95 (or whenever the FPW-VFP transition was).
>

And Fox 2.x was not a monster? Please elaborate on how VB was/is far more stable on the negative side. What is the negative side? With respect to the installed base, it is that installed base that makes inheritance the #1 most requested feature.

>It's a demonstrably a completely different situation. The notion that they can put inheritance and containership into VB just because they did it with apparent ease with VFP is completely (excuse the expression) laughable.
>

I am not addressing the containership issue. I am talking about inheritance. As for being a completely different situation and that my argument is laughable, please provide some quantitative evidence that it is in fact laughable.

Please quantify how they are different situations. It is not enough for you to say that it is different. A cardboard box sitting out in a 3-day rainstorm has more structual stability than the argument you are attempting to make.

According to Craig Bernston, the inference on his side is that it was not easy for the Fox Team to put inheritance in the product. I actually don't know if it was easy or not. I never asked the question. I do know this, they did it in an 18 month time frame...

First rule of debate... stick to the facts.

I have trotted out the thesis that if they did it with Fox, they can do it with VB. You and Craig are trotting out opinions, conjecture, and things you have "heard". In the end, it is all here-say. They themselves do not constitute fact. Fox getting OOP in 18 months and becoming VFP is on the other hand, fact. It was done. My contention is that if they did it once, they can do it again.

If you are going to refute my theory, please do so with facts......

I am one of the few up here you will not let conclusions derived on conjecture as opposed to conclusions based on fact go by....

>Two completely different codebases, two completely different metatdata structures, and an order of magnitude difference in legacy issues (installed base and backward-compatible feature requirements)
>

Metadata structures??? Please contrast the metadata structures of VB vs. VFP with respect to how the path to OOP for VFP would be inherently easier for VFP than it would be for VB....

>Not to say they won't do it. But if it were the slam dunk you allude to, it would have happened sometime back in the 20th century for sure.
>

Did I say it would be a slam dunk?? I don't think so.. I am just saying that it can be done. Both you and Craig appear to be attacking that argument with conjecture and heresay...Talking about rewriting the Kernal, etc... That is all a red-herring. I honestly don't know if it would require a re-write. To me, it is a moot point...

If time is your your argument, then keep in mind this....MS begins the process of developing the next version of software when the current version ships.. Lets see, VS6 has been out for a year... So, in this case, time is not the issue here....

Honestly, I don't know what MS is going to do with the product. That is not the subject of this debate. It is whether or not it could be done. I think it could be done, and in a timely fashion for these reasons:


1. MS has an immense resource pool of talented developers.
2. MS has shown a propensity to get the seemingly complex done quickly - making
VFP OO and becoming the dominate player in the Net are two such examples
to support my argument.


Second rule of debate: Know and understand the points your opponent is making - and attack those - not the points you think he is making...

Third rule of debate: If you are going to bring in supporting evidence for your rebuttal - make sure a logical basis of conlusion can be drawn. Anybody can pick stuff out of the air and make them into facts. Politicians do this all of the time.