>Being stuck with the decisions of previous developers is exactly why I promote mdot. I have seen way too many systems where you cannot tell if it's a replace or an assignment deep in the code, long after the private variable was declared, with the same name as a field elsewhere. That is the real world.
>
>Walter is unwilling to recognize science trumps opinion. No one is calling him out. That is my reason for my recent rants. There are several pretenders in this community who are given a pass.

Mike, you are mixing up things here.
1. If you even started to understand what I have been saying is that mdot is not neccesary if your coding style does not allow any conflict between fields and variables. In case of inheriting an old application where those things are beyond your control you have a very good reason to use mdot.
2. However, what you are doing is declaring your opinion as fact where it is not. I've got a 40 Mb application without any reported problem related to mdot for as long as I can remember because we have strict rules on variable and field naming.

>Walter is unwilling to recognize science trumps opinion
Sigh... Science is the enterprise of gaining knowledge. Even if you stretch the definition of scientific fac, the most you come up with is to describe the facts around using mdot. We do not disagree there at all.

We disagree on the application of mdot which falls in the realm of both engineering and art.
Ergo, your claims that mdot needs to be enforced equals science is false.

The problem is Mike, that none of what you are saying or declaring as fact has anything remotely to do with science.

>No one is calling him out.
Perhaps, they feel I got a point.

And you should have known better than to start lying about your relation to me in the past and what customers thought of our product. BTW, they have been happy customers for more than 15 years.

You knew I was going to bite back and now you cry wolf....

Tsk.