>>>>Perhaps we're misunderstanding (some portion of) what Walter has been saying -- probably due to how he's been wording his responses, along with some conclusions he's arriving at: What I think he might be saying is the following:
>>>>* mdot isn't necessarily bad, but using it as your only defense is bad if you're not using it in *all* cases (where it would avoid potential problems)
>>>>* where you use mdot often depends on context (which isn't always clear [for most people])
>>>>* there are some known cases where mdot won't work -- such as in the case where alias names or fields that clash with identifiers such as THIS and THISFORM, or where alias or fields that are named "M" (IMHO these are "pathological" cases demonstrating problem with poor identifier choice rather than a failing of mdot)
>>>>* if you're not applying mdot where required (to avoid problem), it's not any different than not using it at all (don't completely agree as I see this as a broad generalization)
>>>>* Applying a careful naming convention (consistently) obviates the need for mdot (to avoid variable/field/alias confusion).
>>>>
>>>>Although I agree with careful naming convention could be used to avoid variable/field/alias confusion (such application of convention is relatively easy), I don't agree that it makes mdot unnecessary. I (and others) have pointed out it often doesn't work if you have to deal with "foreign" code or tables (i.e. those from a different party). He makes the statement along the lines of "such code nor tables (that don't follow the naming convention) should never be accepted" -- I would counter that by saying that you don't always have a choice on the matter when you're tasked with interfacing with a "foreign" system. You may not always (typically never) have the luxury of imposing your style or conventions on the other system.
>>>
>>>Hi Naoto,
>>>
>>>Sorry, I can't reply to every bullet in your message, since I've gone through most of them, extensively, with Walter before. Although, I just wanted to say that if one doesn't want to bother with selectively applying mdot based on context, for the sake of keeping the rule simple, mdot can be used harmlessly everywhere (including in front of THIS and THISFORM). However, the extreme cases (of fields named "this", or "m", etc) may fall under the "shooting oneself in the foot" category listed in the links that you and Dragan have posted before, though mdot may be able to diasambiguate some of those, as well.
>>
>>Actually, not everywhere. mdot with a macro doesn't work. That is:
>>
>>

>>&m.cSomeVar
>>

>>
>>is not the same as
>>
>>

>>&cSomeVar
>>

>>
>>Tamar
>
>Here's a few things I use to keep the mdot thing straight.
>
>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.
>
>2 An array isn't a memvar. It's a collection of elements. m.laArray[1,2] makes no sense at all.
>
>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.

You mean the same creators who created the mess about 35 years ago where fields could be confused with variables in the first place and then had to quickfix it with implementing mdot

Yes, that makes sense mike.