>>>>>>>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.

True, but the experience created such a bad taste in my mouth that I'd quickly developed the habit of avoiding mdot if it would be superfluous.
Certain behavior patters take time to die out -- I'd avoided long filenames for quite some time mainly due to the problems I'd run into with FAT and anything built on top of FAT (such as the long filename system in Windows 95). Similarly ran into the problems with Novell Netware (initial version of long filename service used slightly different rules for pairing the long and short filenames from what Windows 95/98 used -- this difference was enough to cause serious problems in certain conditions). Eventually had more confidence in the long filenames after migrating to NT-based OS and NTFS filesystem as well as the switch to a Linux-based fileserver (once I'd figured out how to get SAMBA to work).
The other factor was when need to support FoxPro DOS and FoxPro Windows (i.e. pre-VFP) code was largely eliminated (when 64-bit systems became the norm and Win32 computers were becoming exceedingly rare). That eliminated the platforms where long filenames could be *really* problematic. It also eliminated occasional need to "back-port" code originated from VFP to older FoxPro DOS and FoxPro WIndows.