Hi Walter

I can live with it being used consistently. I think there would be a slight performance hit in this line of code...

m.Var = "Walter"

but there would be a much bigger hit in this...

m.Var = SomeThing

if something is a variable and there is a table open with 255 fields.

Do you realize there are places where you cannot put m.?

m.lcCmd = "?'Hi Walter'"
&m.lcCmd

would crash. Would that again make it too inconsistent for you? ;)

As to consistency, if you use it in a specific case for speed and not in others, that is inconsistent.

I thought of a rule for the correct application of mdots.

Use the m. when the value is accessed, not when the value is being assigned.

The application is consistent with that rule. How's that?

>Hi mike,
>
>>Everything has rules. We cannot write FOR BROWSE. You said we have to know how things work. I agree. I think the impact of putting the m. on the left side of an assignment is minor. The correct usage of it IMO is more important than the consistency, but I could live with making it consistent.
>
>Well, If it is used consistently for every variable in every circumstance I certainly will feel much better.
>
>>>I don't see any significant value in the performance advantages/disadvantages that apparantly exists and seem to differ from version to version. Though percentagewise they seem to be significant (i've measured about a 100% difference with wide tables) in absolute sense it does just not justify the use (maybe in very specific cases). I'm just not convinced any user could tell the difference.
>
>>You are only avoiding the problem while you are in your own environment and you are giving up a little speed by holding to your personal preference.
>
>Yes, I am in my own environment, that's true. OTOH, I have a problem with your statement "giving up a little speed" because this is insignificantly small in all but very exceptional cases.
>
>>This IMO is like a smoker who won't quit despite evidence that it is bad.
>
>I've got a little trouble in accepting you evidence:
>
>1. We've not seen much usage of mdots in about all VFP sample code found in articles available.

We used to see DELETED() tags everywhere. Just because something is done or not done, doesn't make it right.

>2. There is a potential danger, but there are something you can do about it to avoid it.

You refer to conflicts, right? Other than that there is no danger.

>3. If there is a chance of a conflic in fieldnames and variable names there probably is something wrong in either the field or variable naming.
>4. If you can fix this, fix it.
>5. If you can't fix this use m. in the cases to avoid the problem, preferably with a comment.
>


>I don't see any major problem in this approach, nor do I have any problem with the approach of always using mdot.
>
>To me the difference is all just personal preference. I choose not to use it, but don't have any problem with code standards who do use it.
>
>>I for one am very dissappointed that this cannot be resolved reasonably.
>
>I'm not sure what you mean by reasonably. Just accepting the mdot to be included in a VFP coding standard? I've got no objection against that. I've been merely saying that my personal preference is not to use it.
>
>Walter,

I hope computer programmers will be swayed by logic. I'm disappointed that personal feelings and not evidence enter into discussions so often.