>>>>>>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.
>
>One situation where I found blindly adding mdot was actually harmful was when using WordTech Quicksilver (a xBase compiler). If you put an mdot on left-hand-side of an assignment statement, the result was a creation a variable with the mdot as part of its name. The only way to access such a variable was to "double-up" the mdot (and within certain contexts this was not always possible).

Irrelevant as it is not Fox.