Take this code:
Code: Select all
LOCAL myVar
PRIVATE myPrivate
myVar = 42
myPrivate = DATE()
? Type("myVar") && "N"
? Type("myPrivate") && "D"
MyFunction("myVar")
FUNCTION MyFunction (cVar)
? "Inside MyFunction"
? TYPE(cVar) && U
? Type("MyVar") && U
? TYPE("MyPrivate") && "D"
ENDFUNC
In most other development languages local variable names are "thrown away" at compile time and even runtime functions like Type() do not have access to these names.
In the other XBase dialects you would write
Code: Select all
? ValType(myVar) to see "N"
At this moment we are emulating this "visibility" of local variables when you compile Foxpro code with /fox2 compiler option.
Local variables are implemented as "true local variables", but we are also adding the name of the local to a special table in the runtime (the same table where privates are stored) with a code block that allows the runtime to read and write the variables from the locals stack of the function or procedure where the local is declared.
This works, but adding this information adds some overhead to the compiled code and it also produces problems for local parameters declared with the REF modifiers.
We are not sure how many of you are depending on this behavior (that locals are visible by name).
We are considering the following option:
When the /fox2 compiler option is enabled then locals are compiled just like privates. No extra get/set codeblocks are needed to read/write them, and they become untyped (just like in FoxPro)
We may be able to still parse the AS <type> clause and use it for intellisense, and we can probably also use the type to validate assignments at compile time, but the variable themselves will be untyped. That costs some runtime performance, but a lot less than having to add all the get/set codeblocks that are generated at this moment.
The only disadvantage of this is that (at least without extra work) in the example above the call to
Code: Select all
? Type("MyVar")
inside MyFunction
would return "N" and not "U".
Please let us know how important the existing FoxPro behavior for you is and what you think of our proposed solution. Or would you like us to help you clean up your code?
Robert