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

Hi Peter,
none obscure reason.
only that when the arguments leave from a prejudgment based on the use made from the mass,
every argument is useless.

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

If I write m.myVar it means that a field exists of name myVar to avoid? This is illogic.
The correct logic is:
m.myVar it means that i want the value stored into the m.myVar identifier, only this.

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

Peter, UT is not a school one, fortunately for the students,
and everyone can judge the quality of what anyone writes.

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

This presupposes mistaken logic that you have written before.

However I do not use m. everywhere but in some special cases uses
someName
and the code uses the variable one someName if a name field does not exist someName;
this is made by design, and is documented in my code.

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

Bad influnce is a subjective concept,
that it presupposes an appraisal made from someone that has received privileges to judge.
Not me it seems that UT functions therefore,
even if many seems that they want arbitrarily to assume this role.

>Maybe we can vote on THIS ...

A vote is useless,
who want use This can use This, its application will be little slower, but the same one works;
who have understood why it must be used
m.This
m.This.someproperty
this.someobject.someproperty
uses it.
I don't see where the issue is.

Fabio