mdot is not the magical silver bullet to avoid conflicts between field and 'variables'

Consider the following example

CREATE CURSOR Test (This i)
INSERT INTO test VALUES (1)

m.xo = CREATEOBJECT("X")
m.xo.Foo()

DEFINE CLASS x as Custom 
	Value = 2

	FUNCTION Foo
		SELECT Test
		m.oObject = THIS
		WAIT WINDOW m.oObject.Value
	ENDFUNC
ENDDEFINE

The same problem applies to other reserved words like THISFORM, THISFORMSET, or any of the reserved objects like _Screen, _VFP, or variables like _CLIPTEXT, _DBLCLICK etc.

By using mdot, you are not exempt to ensure your fieldnames don't conflict 'variable' names

And it does not stop there.

Lets say you have an application object "Applic" and you use outdated VFP commands like SCATTER MEMVAR in your biz_classes superclass to deal with the entities in your application. what do you think would happen if you dared to have a new field "Applic" in some of your tables and this SCATTER MEMVAR is executed ?

Bang... your application crashes on the SCATTER MEMVAR, leaving the three finger salute.

Now lets be clear, if you inherit an application with existing tables, this might be beyond your control. But if you are creating an application from scratch, you need to have a strategy to make sure the conflicts do not occur. Just using mdot is not going to cut the mustard.

Then there is another problem.

I have not seen any piece of code of any significant length where mdot has been applied 100% consistently. Even the GDI+ library which in general does a very good job on applying mdot, will error out at numerous points. Even mike in his examples fails to preach to his own religion (example to find on the internet).

My conclusion is that is a near impossible job of any project of any significant size to avoid fieldname - variable conflicts. The effort to review your whole project for such potential circumstance is far greater than the effort to avoid using the same naming conventions for fields and variables.


Walter,