[snip]
>>Alan,
>>Read my sig and understand why I commented. Consistency is not the only issue. Standards are also important. Nobody writes m.this, so it is a de facto standard NOT to write m.this. The discussions have shown when mdot is useless. Even Fabio recognizes those cases. For example, the left argument was without the mdot. We should all agree that it's also not done to write m.this, even if it's in the right argument.
>
>I do understand where you are coming from, but I still say that Fabio does have a standard - and a pretty simple one at that. I'm not all that convinced that 'consistency' and 'standards' can exist independent of each other. How can you have consistency without having at least defacto standards.
>
>Fabio's standard seems to be; where there is the possibility of confusion (forget likelihood, I'm talkng about possibility), use 'm.', otherwise, do not. When the variable is on the left side of the equation, it cannot be a field, so there is no confusion and 'm.' is not required. How could the standard be any simpler than that? Maybe if you state your standard on this, it will be as simple as Fabio's, and I will be able to see it more clearly, but it sounds to me like you want a standard that outlines a rule with exceptions.
>
>In any event, I dont' want to beat a dead horse on this because as I said before, I don't do what Fabio does, but when I see a rule/standard as simple and clear as Fabio's, I find it very hard to argue with it.

Alan,
Thanks for posting one more time. For some obscure reason your earlier reply and Fabio's reply too never made it into my Reply section.

I understand your point about 'possibility' versus 'likelihood'. But I don't agree when you write that Fabio's rule is simple and clear.

For one, it could be argued that it is much simpler and clearer to always write the mdot, so also write them in the left argument. After all, only those who have spent time to deepen their knowledge about this issue are aware of the fact that the left argument can never be a field and that the mdot will prevent the evaluation of a field rather than the variable. So, for starters the simplest mdot notation algorithm is the algorithm where it is always used.
For two, an mdot in front of a keyword like THIS suggests that THIS might also be a field! The reader will likely raise his eyebrows, as an indication of surprise. "Hey," he'll think, "is it possible that there is some table here in this application with a field name THIS?" Confusion is the result.

We, the seniors who educate the starters, should tell them about the mdot issue. We must explain when and why to use the mdot. And it is my strong opinion that we must tell them also that names like THIS are forbidden for field names! In a system that has no field name THIS, it is clear that the mdot is not appropriate in front of THIS.

The standard should incorporate:
- Never create a field with a reserved name like THIS.
- Use the mdot in the right argument, but do not use them in front of reserved words like THIS.

I don't mind that Fabio uses m.this in his own code, although I would not like to read or maintain such code. But I think it's inappropriate that he uses that method here on the UT in his examples. It are the starters who get influenced. And it's a bad influence.

Maybe we can vote on THIS ...