Hi Gunnar,

we are talking about different things here.

VFP is not compiled to machine code, but interpreted as the (also compiled) p-code. Each line to be interpreted takes a small amount of time, therefore we declare all the variables as local or private each as one (sometimes continued) line, which will execute faster than one line for each variable.

Then we initialize the variables according to each type in one line for each type. Initializing is especially needed in the case of privates, since the private declaration doesn't create a new variable, but only hides a priviously existing one. If you want to use the new private in a subfunction, you must initialize it before, which isn't always done in the code I inherited.

So I initialize "technically" by just assigning a .f. to all of them, then I can put redundant code into subfunctions and use these privates. During maintainance it is easier, if you add a new variable just to the declaration part and not run the risk of forgetting to initialize - I guess we all know about burning the midnight oil just before the release.

I'ld also like to keep the speed gain of initialzing many variables with one command like in "store" if this is possible - that is the intention of the brackets around some groups of variables needing the same initial value.

This would mean that not only the declaring part is done in one line, but the "lookup" for the value to be inserted into a group of variables is also done only once.

The type declaration in VFP is (at the moment) only for the type libraries, VFP still uses it variant-like variables internally. Giving VFP really different memory variable types (like VB for instance) with an "option explicit" type of setting is something totally different. I personally believe it would speed up development a bit, since a few more errors might be caught at compile time: I started out in strong typed languages, so my preference is a bit tainted by old habit's. You could still leave the default variable type as variant - so nobody would be forced to change *their* habits. If such a program is compiled to machine code, you will see a speed gain: whether that would be true for VFP: I dunno.

To be honest:
I think VFP's main strength is it's data handling ability and speed. The programs I create are "slower" during memvar handling compared to c++ and even Java (Yupp, I ran some tests), but this is offset by a wide margin through the speed in accessing data. The total time of a databound app is still faster by a lot if you know how to feed the fox correctly.

Therefore I personally think the resources would be better spent by building on your strengh's and enhancing the data engine - for instance allowing tables to grow beyond 2GB (my biggest pet peeve with the fox...) - than to implement type-different memory variables. In readonly web apps and pure datamining / datacrunching jobs the added features of SQL server are not needed IMHO, and there I'ld like not to be forced to dance around the 2GB-barrier. PLEASE (anybody!) feel free visit the wish list and vote with a "5" for this item: it is in the top 20 (set preaching off)<g>.

OTOH: if VFP wants to play *in* and not *with* .Net, I guess type-different memory variables are a must.

(rather long winded post, I know)

regards

thomas