David,

I think I see the difference in what you and I are discussing....

>Doug,
>
>>Whoops! Sorry that I misunderstood you. (Oh great, here comes the guilt again.. <g>)
>
>If this keeps up, you're soon gonna owe me several rounds at the next conference. :-)

Just might.. ,g>

>
>>However, isn't that kind of what you really are suggesting? If you remove a feature that some other feature might depend on it seems to me that almost immediately you're in the swamp of unscrambling the internal relationships that have taken years to put together.
>
>I don't think I'm talking about a huge number of limitations.

Well, from my pov we are and I can see why from you we're not. I'll explain below..

>
>>The introduction of random, automatic, in-the-field reconstruction (via command line switches?) so increases the number of permutations that you quickly reach a point of inherent instability.
>
>I have no idea what you're talking about.

Right.

>
>>Then who supports such a beast?
>
>Who supports MTDLL?

Who pays for the support?

>
>>let me ask this and perhaps clear things up: Who makes the decision on what features in FoxPro to include? We all agree that developers decide what features of FoxPro to include, right?
>
>Who made the decision on what to cut from MTDLL?
>
>>Again, I think you have a great idea. I honestly don't think it's practical.
>
>Let's approach this from another angle by taking a specific scenario: Super-fast UI for an n-tier-architected application. No direct data access to tables in the front end, but only through middle-tier business objects and back-end data components.
>
>Leaving out the data commands like USE, SELECT, etc., what VFP features would have to be eliminated and what new ones would have to be added to be able to pre-process the VFP code into C++ code, then compiled native so as to not require a VFP runtime on the client?
>
>Obviously, macros would be eliminated for that scenario. What else would have to go for that to be possible? Might not be a very large list. We would need strong typing, and some other additions, I'm sure. See where I'm headed in my thinking (dreaming)?


Ok.. I'm talking about changeing the actual FoxPro engine whereas, if I'm understanding you correctly, you are talking about what happens when you compile a FoxPro application.

I totaly agree with you that if we could get VFP code to complie to ASM-level code to create a true EXE which would eliminate the need for an interpreter as opposed to the current approach where everything is run through an interpreter with p-code that this would be a good thing.

Then, if I'm understanding you correctly anything that would require things like macro substitution could be constructed into a COM object where we could retain the older FoxPro behavior. Remember true EXEs don't like p-code too much as they don't provide the flexibility that macro substiturion does.

Many moons ago a product named "Force" attempted to do exactly this and they ran into quite a lot of resistance from the Fox community, probably more because of laziness than anything else... They're still around but really not much of a player though they were exceedingly fast relative to the then version of Fox.

Here's a thought. See what you think..

1. SQL as a back end data repository.
2. VFP-based COM & COM+ middle tier objects that could provide macro substitution processes if needed.
3. VPF, VB or Other COM/COM+ middle tier objects that provide other non-macro substitution serveces, each built from the best base product.
4. Desktop UI built from the best base product. I'm thinking Delphi or VB here.

As long as the data being manipulated is not needed on the desktop in the sense that data is brought to the desktop to "chew" on a lot of data (of course we could also create a local COM VFP-based data engine and plug it into a Delphi/VB application), whether because of using COM to do this or not, then I don't see any need for VFP to have to be chosen as the product you build the UI from. VB compiles very well now and uses the same engine that the C++ folks use if I recall. Delphi creates true EXEs - tight, fast and small, and can talk to VFP back ends just like any other product.

In this case, David, you bet, I'm all for it.

My thought was to re-engineer the actual base Visual FoxPro engine itself. Different issue altogether.

Best,

DD