>This approach of evaluating things is to be avoided as much as possible. This is something I learned when moving into this new environment. We got used to that in VFP but, since the first day, I believe it is something that shouldn't have been part of the product.
>
>Interesting. Why do you say that? Sure there are other ways to achieve most things, but reflection isn't so difficult, is it?

No - reflection isn't difficult but I agree with Michel. Reflection is useful if you are working on debugging and code analysis but if you find yourself needing it in normal development work then it almost always implies a weakness in the design.

>FWIW, the "performance hit" from macro substitution/eval() in VFP is very small once the parser is loaded. I've been doing some work looking at _execute in VFP: the only difference is that key words in the evaluated string get tokenized which is remarkably quick for most evals. But you can speed up dense data work in VFP by tinkering with its variable pointers as a strongly typed language would do. More on that later...

TBH I don't think comparison with VFP makes too much sense on this issue. The reasons why you would do it and the way in which it is done are too different.....