>>>>>SNIP
>>>>>
>>>>>>Why do that when it is not necessary, but ignore mdot when it certainly can be necessary?
>>>>>
>>>>>If you find yourself that it is necessary, it already is an indication there is something wrong. Column names should not conflict variable names in the first place. Granted, there are situations where this is out of your control, but in general your naming conventions should avoid this at all cost.
>>>>>
>>>>>To answer your question directly. For me it affects readability. As like Lutz, I hate it passionately.
>>>>
>>>>I don't care what you personally think or do. FoxPro works that way.
>>>
>>>That is a nonsensical answer. Coding practices have very little to do with how a product was designed. The latter is a human readable representation of instructions to the mechanics in the programming language.
>>>
>>>The fox isn't flawless. With the knowledge we have now it would not have been build in the same way as it is. There is a reason there is a good portion of commands and functions that are not commonly used anymore. The mdot would certainly not be part of VFP if it would not have to rely on its heritage.
>>>
>>>So I have no idea, what your implying when you say "FoxPro works that way".
>>
>>He's saying that FoxPro has a way it disambiguates names and you can work with it (use mdot where it's called for) or you can do it the hard way by having a whole set of rules to try to avoid conflict rather than adapting to reading code with mdot in it.
>
>Foxpro offers a mechanism of explicitely differentiate between variable and fields. But that is a far cry from the claim that "FoxPro works this way", as proven by the fact you can perfectly write rock solid programs without it.

FoxPro is built that way. Only an idiot can disagree with that. It looks at a field before a memvar. It looks at an alias before an object. That is how it is built. Stupid to hear from the stupid who don't understand simple facts.

>
>
>>I prefer the easy way. Yes, I also use naming conventions because they help me and whoever inherits my code, but I don't count on them to ensure that a name in interpreted the right way. I use mdot where it's appropriate, I add IN to commands that allow it, and the alias parameter to functions that accept it, and thus I make my code more likely to do what I want it to.
>
>I don't think using mdot is the easy way. Having the same naming conventions for fields and variable is going to confuse no matter how you look at it. Its a design mistake not to make sure that your fields are using different naming conventions from variables. Its much better if your fields are uniquely named within a database that can never be in conflict with variables (I use three letter prefixes + _ ), with the additional bonus that I can also recognize from which table it comes from by just looking at the name. No chance of conflicting with variable names here.
>
>As I said before, even very well established libraries, like for example GDI+ do contain errors that will bang on field-variable conflicts. I've gone through the effort to a lot of those and I don't remember any of them was safe. Just try it for yourself. Create a cursor with fields named _VFP, _Screen, THISFORM or THIS in there and see how many libraries are safe when this cursor is the current workarea.
>
>Unfortunately mdot is an ugly inheritance we in some cases have to use. But I avoid it like the plague.
>
>Walter,