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

But likely doesn't do what's intended. It's rare that the expanded version of whatever you apply the macro to is simply a variable name.

Tamar