Hi Mike,

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

You do know my standpoint on the issue of performance difference in using and not using mdot. At the end of the line it is unsignificant and should not be any factor in to conclude to use it or not.

BTW, I did test this in a 1 million iterations in VFP8 and could not get any noticable difference.

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

First of all how often do you've got selected a table with more than lets say 100 fields in it?
Second what does it mean in absolute terms for your average algorithm.

Those two combine doesn't leave anything left of the performance advantage you're trying to advocate. It certainly won't make anything i've written in the last 10 years noticably faster. OTOH, Making the algorithm more efficient or replacing one VFP command with the other actually is a far better way of improving performance.

This, I see, is comparable to coding an IIF() where a IF ENDIF should be used. The IIF() is faster but can be less readable.

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

>

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

I do.

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

You seem to have much confidence in your fellow VFP programmers. Like described on the wiki there are numerous instances you have to remember wether to use or not to use the mdot. People are not going to understand and remember all those rules. It's too complex, you've got to keep it simple. Why on earth should I replace something that has been accepted in the VFP community for years (at least back into the fox2x days) while being aware of the potential danger of field and variable conflict , with something that is difficult to remember.

If we should introduce a standard where m. is used than at least make it as consistent as possible and easy to remember. The fact that you cannot use mdot in a macro is a language limitation (which might be changed in future versions) and we've to make an exception for that.

I'm asking myself the question, why should I suddenly use m. while 90% of all VFP programmer in the last 15 years did not use it? Why do I when I look at articles (magazines, KB, article) so little mdot used ?

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

That would be very, very rare, and if I for some reason have to use it for this argument I would make a comment explaining why I did it. But since I do not see any application for it in anything I've build in the last 10 years, I would guess I never need this.

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

I still find it too clumsy. The fact alone that you type the same variable in two different ways is odd to me and you would not find that anywhere outside the xBase world. For a newbee this is really just confusing.

About your rule, I think the wiki reference you gave still mentions exceptions to this rule, where VFP does not let you do this.

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

DELETED() tags had a serious disadvantages in a lot of cases while it did about nothing to improve performance. A few years ago, at last there was some scientifical evidence about what the DELETED() tag really was, that changed all. The mdot only avoids a very specific problem that IMO should not arise anyways. This problem has been known all right from the start, so why should all of a sudden fix the protential problem is beyond me.

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

When something is simply a matter of true or not true, complete or not complete and even misleading, this can be solved by scientifical research.

However when talking about something abstract like a coding standards personal preferences come into play. We should all accept that we've got different coding preferences. But maybe a code standard could just describe two or more variations on a subject like naming variables. Just as long as its used consistently I don't have problem with it at all.

And don't get me wrong, I don't have any personal feelings against you at all. It is just that I don't feel comfortable with your proposed mdot usage.

Walter,