PMFJI, I think that a SET or SYS() setting to determine memvar accesses would require some major overhaul to the VFP code base. The fact is that VFP ALWAYS looks for a field with the referenced name FIRST, so there is no way to resolve an ambiguous reference to favor the memvar when you have a visible field and variable with the same name without using Mdot. Otherwise it would require changing this lookup method that is and has always been an intrinsic part of VFP.

IF you had a sys function that says that memvars are not to be referenced by M., then for that to really work in the case of ambiguous field/variable reference, it would have to allow the variable to take precedence over the field in those cases. That would then be just the reverse of the situation that exists now and in order to access a field, you would have to prefix it with the alias name.

That seems a little like a Rube Goldberg solution for a problem that really doesn't exist, as it is documented that VFP always gives fields precedence over memvars of the same name and Mdot is the method to force reading the memvar over a field of the same name that will prevent ambiguity. Also VFP is a little more forgiving than many other languages in that if you don't want to use Mdot, for whatever reason, you don't have to but you still have to live with the way VFP works and accept the responsibility and consequences of your own mistakes in code due to potential ambiguous references.

I personally favor using Mdot for variables and alias.fieldname prefixes to reference fields. I find it helps make my code more self-documenting and removes any question as to which is which without having to dissect the code, but that is just my style.


I have no idea how much re-factoring of the VFP code base that it would actually take but I would assume it to be a huge task. My guess is that it probably will never be undertaken since there already is an effective mechanism to prevent this ambiguity and associated errors by using Mdot.

Just my $0.02