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

>>>>>>
>>>>>
>>>>>I would say that in &m.cSomeVar you are macrosubstituting m. If you'd want to apply it to var you'd have to issue

m.&cSomeVar

which works for plain values and object references.
>>>>>*
>>>>As has been previously pointed out, code like the following:
>>>>

cSomeVar = "? 'Hello, world'"
>>>>&cSomeVar.

>>>>will break if you do that.
>>>
>>>Yes, it will break because it is not used as intended or documented. In the statement above, you would be substituting the string "cSomeVar" with the string "? 'Hello world". It is same as
>>>

>>>#DEFINE cSomeVar ? 'Hello world'
>>>cSomeVar
>>>

>>>In other words, cSomeVar is not a true variable in that context. It is the plain string "cSomeVar" substituted with something else. Thus, attempting to treat it as a var should fail, as it does.
>>>*
>>
>>There is a subtle, but important difference. Using a manifest constant (i.e. a #DEFINE) the replacement is performed at compile time (i.e. when the text is transformed into p-code). On the other hand, macro expansion is performed at run time. I could change the contents of the variable used in the macro expansion at runtime and affect what the macro does.
>>
>>Back in the old dBASE III days you might see on occasions macros to implement what could be called "pseudo-array" (since the language didn't support subscripted variables).
>>

foo1 = "fee"
>>foo2 = "fie"
>>foo3 = "foe"
>>foo4 = "fum"
>>for I=1 to 4
>>    cIdx = ALLTRIM(STR(I))
>>    ? foo&cIdx.
>>endfor

>>Conceptually it's not too different from what was sometimes done in scripting languages like EXEC, EXEC2 and REXX under VM/CMS.
>
>The only difference between &cidx and #DEFINE cidx is the stage at which the substitution occurs. In the case of #DEFINE the substitution occurs at compile time, wheras in the case of &, it occurs at runtime., Like a runtime compiler, if you will. But, it does the same thing: it replaces one string with another, and if the result is not a valid statement, you'll get an error. It has nothing to do with variables, per se.
>*

Perhaps there is a bit of miscommunication going on here. What I've been saying (as well as others) is that in the context of a macro, the identifier specified can only be a variable (i.e. cannot be a field) -- thus the mdot is NOT required (thus in this way it DOES have to do with variables). Additionally, due to the particulars of the syntax you DON'T want to use mdot (and as has been stated previously, the meaning completely changes from what was probably intended).