>>>The requirement of using m. is negated by using LPARAMETERS and LOCAL declarations for every memory variable, using prefixes like "l" for local, "g" for global, "t" for parameters, with a second character indicating the type like "l" for logical, "c" for character, "n" for numeric, "i" for integer, etc...
>
>That doesn't undo the performance hit from not using m. on the right side (after) an = .

Never one time have I have had any performance issues in software that could've been improved by using mDot. They have always been the result of network file access, UI limitations, or other such things.

>Having reviewed such things carefully, I'm satisfied it makes a difference especially if the selected table has lots of fields, since VFP has to check whether there's a field of that name before using the variable and it takes time. That *you* can be certain you'll never name a field that way, doesn't assist VFP.

VFP is so fast that it's a non-issue. Our biggest need for speedups is a faster network. When multiple users are on a FoxPro-based file system network, data retrieval can be slow. We have used various design techniques to negate that, but it is our only true issue related to anything VFP-related.

>It's a little like automatically putting on a seatbelt for me. I'm not planning to have a crash, but planning includes preparing for the worst, not just anticipating the best. After a while it's automatic and no stress at all really.

It's not like having seatbelt. No lives are at stake. At the most it's data. And we have multiple redundancies in our data storage system so that even if entire records or files were wiped by a system crash, we could reconstruct them via journaling.

It's a non-issue. Use mDot if you desire. I'll do the same.