Learning mdot Usage

Seeing that there are still a lot of VFP users confused with the usage of MDOT (m. prefix), I decided to create simple explanations regarding this.

When mdot usage is mentioned, a lot of developers argue about whether it is really needed or not.  And as usual with developing there are a lot of ways to do things (skin a cat as Mike Yearwood fondly says) and so every time a thread or a post is started regarding this, it came out the argument seems to be endless.

Originally I titled this “Delving into (un)popular argument, MDOT prefix” because it is a popular argument where threads became long but some think of it as an unpopular way. LOL!  Later I decided to simply title it “Learning mdot Usage”.

Well I am not here to argue whether mdot is really needed or not.  What I am after here is if you will decide to use this, at least you know how properly.  Fair enough?  Then let us go on with the topic:
Let us take a look at this equation:

WholeName = FirstName + ” ” + LastName



What will happen is when VFP sees the above, it is clear to VFP that “WholeName” is a variable (we will explain this later) while in case of “FirstName” and “LastName“, there will be a little confusion because there is a possibility that one or both can be a field name of a current active table or a variable.  That confusion is what is later  came to be termed as “ambiguity” over field  and variable name.  To avoid said ambiguity, VFP has created this rule within itself to:

a.  Consider it first as a field name of the current active table.  VFP will check if there is a field of the same name and when it found one on the current active table/cursor, stops there and says to itself “FirstName” is a field.  Period.  Since a field is found on the current active table with the same name, it will no longer look beyond that.

b.  When it cannot find a field of the same name on the current active table, it will automatically be treated as a variable.

So you see now how things are decided inside VFP?  Field Name first, variable second.

Now, why do some developers prefer placing an mdot prefix then? Because when you do prefix something with m., you are telling VFP that that is a variable.  Period.  By doing so, you have taken over VFP’s way of checking things. When an mdot is prefixed on a variable, VFP will never look anymore for a possible field of the same name.  Checking the current active table will be skipped.

WholeName = m.FirstName + ” ” + LastName

In the above equation, VFP will treat this now as:

a.  WholeName as variable (again we will explain this later)

b.  m.FirstName is also a variable (made absolute by mdot prefix)

c.  LastName can be either 1. Field Name or 2. Variable (ambugious declaration)

Again as you can see above, priority is field name then a possible variable later.

When both field or variable of the same name do not exist, you will have “variable ‘LastName’ is not found“.  Why so?  Why never “fieldname ‘LastName’ is not found“?

Again, field first, variable second.  VFP checked for a field name, it does not found any, tells itself it must be a variable; also does not found any, then since it is now on variable checking says that error.  There will never be “fieldname not found” error because there is always the variable checking fallback.

Last, we will now go to “WholeName“.  I said it is absolutely a variable.  Why so?  It does not have any mdot prefix so why am I very sure that it will never be treated by VFP as possibly field first then variable later?  Answer is because in VFP you cannot assign a value to a field that way, so there is no ambiguity whatsoever.  So doing this prefix in WholeName is useless:

m.WholeName = m.FirstName + ” ” + LastName

And if this is useless, then why do it?  There is absolutely no need for an mdot prefix on the left side of the equation.

For some, the word “ambiguity over field and variable name” is really ambiguous/confusing.  I hope that with these simple explanations I have come up with, it will no longer be ambiguous to you.