Hi Mike,

>First please understand I have no negative feelings as I write this. I'm writing this with the feeling I have for a chess game. It is an enjoyable intellectual puzzle.

I have got a very thick skin. Sadly I'd expect other to have one as well ;-)

>You admitted there is a difference with using mdot on the right side of the equal sign. You admitted that performance is adversely affected by the number of fields in the table in the current work area. You even mentioned it in this very thread. You didn't say anything about how code that doesn't use mdot can be broken just by adding a single field to a single table. You cannot control who will inherit your systems, but you can make sure they can't break your code.

I fully agree. People can workarround this issue two ways:
1. Use the m. notation
2. Avoid conflict with field reference

I choose the latter as I PERSONALLY feel uncomfortable with m. and because I PERSONALLY name fields in a DB with a tree character prefix to make them unique accross the database I don't have any problems here.

>A single mdot makes the code faster when no table is open. It is even faster when a table with a lot of fields is open. There is never a loss of performance using mdots. Furthermore, the code will not crash for any outside reason! No one has ever shown a reason not to use mdots. Some choose to write the following code by putting the mdots everywhere. That is redundant, unnecessary / wasteful and slower. If one does that, I hope they do it with the knowledge that it is not the optimal way. To the best of my knowledge, with everyone I've ever confronted with this failing to find physical evidence against it, this is the best way to use mdots:

Well, one could argue that this is inconsistent because you reference variables in two different ways. Also, the rule of the "left of the equal sign" is not complete either. Remeber that the equal sign is used for two purposes: 1. Assignments and 2. Comparison. When assigning you could omit the m. and with comparison you'll have to use the m. notation to take advantage of the performance advantage when having a table selected with a large number of fields.

This of course exaclty what I'm getting at. If you describe a rule "Don't use a m. at the left of an equal sign". Explain the technical background. Because for the equal sign used for comparison this rule does not apply at all in the first place.

Of course there is alway the matter of common sense. Does the performance issue really matters here? I guess not. The difference indeed could be significant when talking about percentages but in absolute sense it is about inrelevant. The time to process the variable with and without m. is so small that is overshadowed by an other performance problem in the system. If the difference of 1 million processed commandlines is about .01 seconds, what are we talking about. It makes sence to keep all things in perspective. Only in very specific application it would make a difference, but even then I'm starting to wonder If such module should not be written in another language like C/c++


>You said we should know when to use macrosubstitution. I argue we should know when and how to use everything. That includes DELETED() tags, SPT or Views. You argue that Craig's examples are just his opinion.

No I don't think that all craigs example are just his oponion. Some of rules are expressed such way that they bu default are read as the absolute truth. This is exactly my objection.

>I think I explained all the reasons for using mdots. You even duplicated my findings and expressed surprise.

I did, yes. However I did also said that this finding for me is not a reason to use m. right now. I'd expect that the sample you've given is not complete yet. This really deserves another thread, but I expect that the performance of processing a variable is also very much depended on how many variables are in memory or in scope. This is one aspect we did not investigate yet. If we then take into account that in a general application there are more variables in scope or memory the performance difference get at another percentage level as well.

>With respect and no intention to insult you, Walter, I remind you that you told me you wouldn't use the mdots because of readability. That made me think you are saying my way is not "readable", as if "readable" is some global standard you invented.

No, I did not mean that. As I said this is PERSONAL preference and therefore there are so many difference coding standards. Readability is up to some level personal.

>On the issue of mdots, given a choice between having stable code and having readable code, I choose stable. The mdots don't reduce readability as much as they improve stability. Once you get used to them, it is easy. Isn't this what Peter meant when he said, we should teach the good techniques, but we should be able to adopt new techniques when they are demonstrated?

Well again, it is just the issue of how to avoid the problem of beeing sure you referrence a variable in stead of a field. As I said before you can do that in two ways. You choose 1 and I did 2.

>I think you should not be so hard on Craig until you agree that you should use mdots everywhere (properly of course) because you used the same arguements against Craig that I used on you <g>.

Sorry I can't see that. please explain....

>Hopefully, this will neither anger nor frustrate you.

It did not :-)