I've given up trying to convince you of anything. That is a waste of time. I did not address you this time either.

However, it is dangerous to smoke a cigarette while trying to pump gas into your car. Your concern about the readability of the code is like saying "I look cool with a cigarette". You are also saying "I'm careful with my cigarette" and "Nothing exploded yet, so I'm safe".

It does not change the fact that you *are* smoking a cigarette while pumping gas. There is a chance things will explode. I prefer not to take unnecessary risks.

I understand you want to continue to smoke and pump gas. That's your perrogative. I just recently had to deal with another missing m. bug. So you may be safe in your little world, but in the real world, this is a real issue. It is unfortunate you cannot see it.

I will not be discussing this issue with you again, so please do me the same courtesy.



>Hi Mike,
>
>As Fabio said, using m. strategy in itself does not prevent you from the problem, if in one instance you forget the m. and now inmediately confuses fieldnames for variables. This problem is more likely to occur when:
>
>1. You don't use m. consistently (but use what is suggested at the wiki)
>2. You don't use naming conventions to avoid collisions between fieldnames and variables.
>
>>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.
>
>I know several good VFP developers who do not use m. FWIW, I do regard myself as a resonable VFP developper and do not have any problems without using m. so, your point is ??
>
>>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 do miss the use of naming conventions to avoid collisions here to avoid problems in your analogy. Again you're fighting an academical battle that might have reason in strict theory. However in practise this is a non issue in my experience. And even then the theory is not complete either. You'll have to use strategies to avoid collisions with VFP keywords like THISFORM and THIS and with object valiables, like Fabio is proposing. To apply m. for security reasons and leave a gap open often is more worse than no security att all.
>
>Again, my personal preference not using m. is outweighing the strict theorectical chance that somewhere In the future I'm going to be bitten by confusion of fieldnames and variables and I've got to fix that problem when needed. I'm certainly not willing to decrease the (my) readability of sourcecode that has a far worse potential source of bugs than the problem you are describing.
>
>IMO, this is one topic that continues to be a fight between camps and does not have any significance in VFP development in general. IOW it is just a waste of time one camp trying to convince another: Not very productive.
>
>Walter,