>I am most curious where you got the idea that you
>could make a suggestion in the Thor forum and it
>would be up to somebody else to write the code
>or you.

I offered to code it or large portions of it. What I received back in several responses were negatives (replies that began with something like "Unfortunately..." or "That would be nice, but..." or "It wasn't designed to...", etc).

I came away with the impression that Thor was not really capable of doing what I asked, nor were any of the developers involved desiring to step outside of the existing methodology of processing "m." prefixes to examine the request from another perspective. In addition, it seemed the necessary infrastructure wasn't there, as there were planned future features which were currently of low priority necessary to make it happen which may or may not come into existence, and the algorithm which processed the "m." prefixes did not know where the file came from, etc., so there was a disconnect internally about how it could be stored.

All of these factors indicated to me a lack of desire or belief that the suggestions I made warranted inclusion. And in short, the attitude I received was of such a kind that I moved on to complete the work in Visual FreePro.

>If this issue is so important to you and the amount of
>new work, as you say, "would not be significant", I
>have to wonder why you have not already created it.

I have all the pieces already built, as likely is already done in Thor. These pieces will be assembled into this concept and integrated into Visual FreePro (James 4:15).

I have not already written it because, like you, I've never seen a need to code "m." prefixes on every variable reference, so I've never needed it. It was only after the consistent insistent positions offered up by Koen (who remains absolutely adamant to this day), and Tamar, and a few others, that "m." prefixes were ABSOLUTELY ESSENTIAL that I began to realize that they are essential IF the ONLY tool you're using for validation or security is VFP itself. But, if instead you can validate EXTERNALLY (via some tool like Thor) that no such name collisions exist in your project, then the "m." prefixes can be removed in all areas except where foreign tables will be opened and used, and your code can be much cleaner. And, as other people have indicated, the performance hit by not using "m." prefixes is negligible.

Ultimately I worked past this issue in Visual FreePro by employing two new features, so it's not really needed anymore. I have introduced two settings, SET VARIABLESFIRST ON|OFF, and SET CASESENSITIVENAMES ON|OFF. Both of these remove the need for "m." prefixes. VariablesFirst does it by looking to memory variables before table variables (of which I've also introduced the concept of t.FieldName in lieu of m.VariableName, to indicate that a reference explicitly comes from a table/cursor), and caseSensitiveNames will maintain the case so that you prefix memory variables with two lower case letters first, and table names with a single lowercase letter first, and there will never be name collisions even if the names are the same sequence of letters and numbers (due to the case making them different).

And beyond that, when a naming convention is in use, such as memory variable format of "llFoo" or "lcName" or "lnEstValue" coupled to table field names of "lFoo", "cName" and "nEstValue" (which would've already fixed itself by being different names in nearly every case, but for the cases where there's a logical value called "lNestValue" the ability to use case-sensitive names now removes that issue as well).

I have also introduced a developer debugging tool called ON COLLISION which works like ON ERROR. When enabled, it will exhaustively search beyond the current SET VARIABLESFIRST ON|OFF status to see if any other identical names, case-insensitively, are found, and if so will call the ON COLLISION code with the information. This will allow the feature to be turned on during development and testing, and all references where collisions exist can be documented and corrected, with the ON COLLISION code ultimately being turned off in production.

Visual FreePro will remove many shortcomings inherent to Visual FoxPro (James:4:15), as well as extend many of the ideas VFP introduced but failed to see all the way through due to Microsoft's agenda, and it will do so in an xbase framework with C/C++ (and ultimately some Java syntax extensions).