Input needed on FoxPro local support

[atlopes]

Robert,

Thomas is already giving you plenty of food for thought. I'll just add a small remark around this,

However a function such as Type or Eval could also receive a string in the form of:

Code: Select all

Type ("MyLocal = 10")

which is an assignment. It should still return "N" because the value in MyLocal is numeric after the assignment.

hoping it will help to clarify how TYPE() works in VFP.

The argument of TYPE() is a string representing an expression that can be highly complex, just like in EVALUATE(). The difference between the two is that TYPE() returns the type of the evaluated expression, while EVALUATE() returns the result of the evaluated expression.

In both cases, the full-blown VFP evaluator parses and calculates the expression. The scope for the expression is the scope of the caller.

"MyLocal = 10" is not, in any case, an assignment: it's a logical expression, with two operands (MyLocal and 10) and an operator (the equal comparison operator). It will return "L" when MyLocal is numeric, "U" (for undefined) in every other case, including when MyLocal is not a valid field or variable name.

If the expression fails to resolve properly, TYPE() will return "U". In fact, I use TYPE() whenever an undefined result may be returned, and VARTYPE() in other cases. TYPE() is completely safe to not raise an error as long as its argument is a string.

A final point: TYPE() may receive an extra numeric parameter holding the value 1, to indicate that the code is querying for an array. In this case, TYPE() will return "A" if the character expression represents an array, "U" in every other situation (even if the expression evaluates successfully).

[robert]

Thomas, Antonio,

The fact that "MyLocal = 10" is a comparison and not an assignment is the perfect example to me that the use of the '=' operator for 2 different operations (assignment and comparison) is really a bad idea.
That is one of the reasons that most of the other XBase dialects have chosen the ":=" operator for assignments.
We had a discussion here a while ago about an example like this:
a = b = c
and in that discussion we agreed that the first "=" operator was an assignment and the second "=" operator a comparison.
I do not understand why this expression
Mylocal = 10

should now be a comparison and not an assignment. It simply does not make sense.

Robert

[Zdeněk Krejčí]

In VFP: If "Mylocal = 10" should be an expression, it cannot be a command - assignment.

Zdeněk

[robert]

Zdeněk

So what you are saying is that VFP only has an assignment command and not an assignment expression.
That is quite different from most other development languages where something like this is also allowed:

Code: Select all

LOCAL nDow 
IF   ( nDow := DOW (Date()))  == 1 
    ? "Today is Sunday", nDow
ELSE
	? "Other day", nDow
ENDIF

I checked this example in VFP and (when I replace the ":=" with "=" to make it run in VFP) it indeed complains "Operator/Operand type mismatch" because it tries to compare the .F. value in nDow with the number returned from DOW().

Robert

[atlopes]

Robert,

Even if this will add not much to the thread's main issue, I believe there is no way to make a VFP expression assign values to variables unless as function arguments passed by reference.

[Eric Selje]

Nor should they ever.

TYPE("MyVar = 10") is a character string and should never assign any value to any variable.
TYPE(MyVar = 10) might return a boolean if MyVar is numeric, otherwise it will throw a type error.