>>>>Hi.
>>>>
>>>>does it make any sense to have mdot used like this
>>>>

>>>>m.ObjName1.Name2()
>>>>

>>>>?
>>>
>>>mDot is how FoxPro works. Computers are fast but stupid. If you can deliberately tell Fox what is a memvar vs a column, your code is clearer. The speed gain can be significant at times. Why not get it for free. It is nothing to do with personal preference.
>>
>>There is no performance advantage in this case. It does not apply to expressions that are objects-properties/method references
>>I would not hire anyone who insist on using m.THISFORM or m.THIS . Its silly to use it on objects.
>>
>>For usage on variables, its a choice, one of personal preference. I hate it. To me, in general, the less code, the better it is to read. And if it is not clear whether the code refers to a variable or a field, its a sign there is some room to improve your coding standard.
>>
>>Be aware of potential conflicts and adopt proper coding hygiene, The naming of fields and variables should be clear or else it would be a source of bugs no matter whether you're using mdot or not.
>>
>>I've found no single open source/third party source of any respectable length, using mdot that is free of potential variable/field conflicts.
>>Common sense has to be used.
>>
>>I find myself only using mdot, where performance is absolutely critical and can improved using mdot, which is extremely rare nowadays.
>
>[shrug] I tend to use mdot whenever there could be an ambiguity, but I don't however *blindly* apply mdot in context in which it can only be a variable reference (e.g. on left-hand-side of assignment, passing variable by reference, macro substitution, etc.)
>Indeed you can solve a lot of problems at design time -- but that's not always an option if you're writing code that might interface with code or tables that you had no input on its design.

Indeed, if you inherit code this might be out of your control like many other things. And I agree, adopting it where necessary it a good strategy.