>>>>The sad thing about Thor is that it also has the ability to validate whether or not there are any name collisions on a system when you know all of the tables in use, and have all the source code, yet such a report will not be created due to reasons specific to its developers' beliefs that the only proper solution is to prefix everything with "m." on variables.
>>>
>>>Rick --
>>>
>>>Please explain this statement. As far as I know, and I am the creator of Thor, there is no belief "that the only proper solution is to prefix everything with "m." on variables." In fact, I do not use use M.Dots (horrors!), nor have I ever encountered name conflicts as result thereof
>>>
>>
>>Jim,
>>
>>The fact that you yourselve have never ever encountered a name conflict although you donot respect the m.Dot prefix does not qualify the use of m.Dot to be something 'horrible' .
>>
>>Fact is that by using m.Dot you will be guaranteed that your code cannot be broken or clashed when using as a procedure by an other programmer. It is a must, in my opinion, to make use of m.Dot in case you want to produce truly generic code. The disadvantage, in most of the opponents of using m.Dot is that it looks 'ugly'. Remember it is only coding and nobody can see the code, you are suppose to use it.
>>Luckely we have nowadays a procedure which can correct our codewriting to make it fully m.Dot compliant.
>>I remember one guy who was just like you, he was making all kinds of beautiful graphic applications for generic use, coding without m.Dot. The guy was facing a search and debug in his application for a whole day on a bug nobody else experienced, he could not reproduce. Than all of a sudden he realized the guy reporting the bug used a table with field(3) = N - of course you are correct this is a stupid thing to do - but my friends beautiful graphic application crashed on a line with if lcVariable = n and would not have crashed on if lcVariable = m.n
>>Please reconsider before you say again that m.Dots(horrors!)
>>
>>Best regards,
>>
>>Koen
>>
>>P.S. better start a fresh/new topic about this matter as it seems we are a little bit away from the original subject
>
>First, Jim didn't say that using m. is horrible. You totally misread his statement and as result you are arguing with yourself.
>Second, I'm with Jim on not using m. It's not necessary at all to produce safe code

I, too, thought Jim did imply "M.Dots(horrors!)". To the technical point: What if you had a field named lcx, or whatever. Shouldn't you stick to a naming convention (which may require more effort than a simple m.dot rule)? Considering the risk, I consider the lack of enforcement on m.dot to be a limitation of VFP. Apparently, the issue has been debated before: http://fox.wikis.com/wc.dll?Wiki~EssentialMDot