Craig,

>>
>>That's easy to say when you're not paying for it. <g>
>>
>>Disabling a command isn't the same as removing it or never inserting it to begin with. Additionally, I stand by my assertion that to remove a few commands from VFP will essentially do nothing whatsoever to bloat or speed. You'd have to take a meat axe to it and there would IMO be no end of change or enhancement requests to MSFT. "Please allow us to take this out, put that it. No, not that way, this way. No, not this way, that way ad nauseum." That would drive support costs through the roof IMO and would be the quickest way to kill the product.
>
>Doug, this is what the Fox team has been saying for a long time. You won't get much by trimming out the old stuff.

Yes, I've been hearing that for almost 15 years now. I really do think that David's goals are extremely laudable. I think that there are essentially two options; One would be to completely gut the current product to create something new. David wants to go one way, I another. The second is to continue to extend the current product but keep its current functionality and features and let hardware render the "bloat" irrelevant. I'm sure no fan of said Christmas-Tree-Itis but there's this very difficult issue of determining how to best carve the product into the various pieces and parts. No matter which way you go someone will be damaged unless you granularize everything. To do that would be great but as I pointed out to David, if you only chose a half dozen of those pieces and built your product you'd end up essentially back with the whole product again because of the need to pull all dependencies in as well. I see no real advantage there.

Now.. If you could take out JUST the macro expansion stuff and trade that for up-front variable typing and declarations, ok, I think you might have a case but I'd still think that this would cause troubles. Then there would be multiple version of VFP for MSFT to support and everything dissolves from that it would seem.

If the Fox Team ever decided to rewrite the product from the ground up and give us the features David is asking for and could pull it of I'd be the first person in line to support them. I just don't see it happening though. For me it's the difference between what I'd like to see and what I think is practical in real world terms.

Again, if you want a small EXE on the desktop use VB or Delphi. Even in these cases you get those mammoth support libraries which really are just another way of packaging product. The only real way around all of this is to hand roll everything in assembly IMO. Who's going to do that? <g>

>
>>
>>Yes.. There was no other way to make it work in the real world because of the nature of compilers vs interpreters. You had to declare everything up front. It wasn't a bad idea, rally. It forced developers to be disciplined and that IMO is what killed it. Developers were more interested in having their own way than having a fast product. Force was/is a VERY FAST product.
>
>I remember people asking Nantucket to create smaller EXEs. The Clipper team would always respond with "We have to leave everything in for macro expansion".

Right. It's really just an issue of tradeoffs. Get this, give up that.

Best,

DD