>Chen--
>
>There has been a long running debate by VFP developers on the use of m.dot for variable notation vs. using just the variable name; i.e. using a variable name as "Variable" rather than as "m.Variable". When a named variable such as "Variable" is first encountered by VFP, it has to determine if it is a table field or an actual variable. If a table name is found with a field name the same as the variable name, then the value is assumed to be the field value. However, if the variable is prefixed with a m.dot (m.Variable) then VFP processes it only as a variable. Additionally, if fields are referenced only by their names (without the alias name) then the same collision could occur if two tables have fields that have the same name and neither table is the current selected table -- in this case the first table would be selected which might not be the correct table. In my opinion table fields should always be referenced with their alias; i.e. tablealias.fieldname. And, then variables are referenced by their names. The two are never mixed.
>
>I always found the VFP compiler behavior to be a very sloppy practice (in general I find that xBase is a 'sloppy' language which is my opinion). I much prefer not to use the m.dot as I see it 'cluttering the code' and not providing any real value (other than to the compiler because of its sloppy behavior). In my opinion, programmers are developing code to make their user's jobs easier. In the case of VFP compiler, it should make the developers job easier (i.e., not require cluttered code).
>
>So would it be possible to enforce the following in the Advanced VFP Compiler (Can this be controlled via a compiler directive or switch?):
>
>1. Variables must always be declared as LOCAL with a type or as passed parameters with type. I would not want PRIVATE or GLOBAL permitted.
>
>2. Can variable types be enforced? The default value assigned is based on variable type; i.e., Integer/numeric values would default to 0 or 0.00, Boolean to False, Character/String to "" (empty), date to the current DATE value, and any object variable to NULL. Now in doing this there should be a type that is a variant which is determined at run-time...
>
>3. Can field names only be referenced by the alias as in tablealias.fieldname? If a field is referenced without the alias, it is a variable and if not declared in a LOCAL statement then it is a compiler error.
>
>4. The use of m.dot is permitted for backward compatiblity but not required. Variable names must be declared as LOCAL
>
>Thank you.
>
>Greg

We use the technique of ambiguous name by design.
Normally, the data is read from the table,
with a default value in a variable with the same name.
If the table does not have the filed then the value is used that is in the variable.
It is risky, but with a little care, is a technique that simplifies lot code written