>>No one is pushing anything down your throat. The fact is only dbase-like languages have this issue. How you deal with it is your affair. I know several really good VFP developers and they're using mdot. IMO technical reason must outweigh personal preference.
>>
>>To use analogy, most programming languages are like pants with buttons in the front. VFP is like pants with a zipper. There is a chance that something might get caught in the zipper. I think wearing underwear will reduce that risk. You can certainly arrange things so nothing gets caught in the zipper. Also, in the case where the temperature gets down to -30C, you will be less ... protected. You'll still have risk. You won't be able to zip up quickly and without care. You don't want to wear underwear because they make pantylines on your ahem ... backend - you don't like how they look.
>>
>>I think it's just easier to put on the underwear! I'm talking safety, you're talking fashion. ;)
>>
>>How's that? ;)
>
>Hi Mike, I do not want to speak for Walter, but i think that he has understood all the differences.
>
>You speak about safety,
> but is more probable to have one field-variable collision with the Walter's protocol (totally different syntax names)
>or with equal names (SCATTER TO MEMVAR) and always using the prefixed one mDot?

Neither is more probable. If I always use m. I will not have a conflict. A mistake can be made in either scenario.

Using m. will prevent that mistake from happening. Using m. and a naming convention will virtually eliminate such mistakes.

>I make a speech of formal correctness, not of safety.
>If we want the safety, the VFPT must add a SET that it obligates to put mDot for get a variable's value.

Mdot is a fundamental issue in FoxPro. There is no need to take a risk, when a simple preventative option is available.