>>>1 A macro isn't a memvar. The second you use the & you have a command. So no mdot is required. However, the second I use & I immediately add the trailing optional period, just as I add the trailing ) after using a (. This practice means any time I use macros within an object reference, I automatically get the .. correct.
>>
>>Which my eyes always perceive as a travesty, but does not alter the soundness of the practice ;-)
>>
>>>
>>>2 An array isn't a memvar. It's a collection of elements. m.laArray[1,2] makes no sense at all.
>>
>>Esp. as it will run a such-named program if no array of that name is in scope ;-))
>>
>>
>>>3 an object is stored in a memvar.
>>
>>>4 use mdot everywhere it will permit you, even in assignments, even and especially if you have a naming convention. Mdot is built into FoxPro for a reason. I trust the creators of the language far more than the Hungarian notation camp, and far more than the most vocal mdot naysayers.
>>
>>Disagree personally on the left side of assignments. Adds typing AND small, but unnecessary CPU load.
>
>That is well compensated for because in the debugger, hovering over any variable with the m. will show the variable content, not the field content.

The source debugger works according to the general foxpro rule, showing a field value instead of the memvar value when no m. is there.
If there is no identically named field, the debugger will show the memvar value quite nicely. I use naming rules AND rightsided mDot and trust that in debugging the naming rules work. Scatter default target for me is "Name" (in FPDos was Array) and I think there were only 2 occasions where I used Scatter to normal memvars for performance reasons - well bracketed by dire warnings in comment lines.

So while true, for ***me*** no reason to switch: my typical debug style is to add vars to watch window, there of course mDotted, instead of bird style picking in visible source.