>
One thing where we quite often use macro expansion is when we want to make something data driven. It can be a menu, a list of objects which should appear, or an object factory with the names of the classes to be instantiated stored in a table. You name it - many Foxers are using these things. The mere ability to make things data driven was a good way to get things more easily maintainable, apps more flexible, and life easier in general.
>

IMO, using macro expansion and data-driven code, while related, are substantively different things. In other words, if you use macro expansion, you may use data stored in a table to drive that process. Conversely, just because you use data stored in a table, you are not neccessarily using macro expansion or eval() for that matter.

To illustrate, I could use a variable to reference a class I wish to instantiate. I am not sure of the technical details yet, but I am willing to bet there is a way to do this in VS .Net. (I am anxiously awaiting for my new dell box!!).


>The other thing is the bunch of places where VFP uses eval() internally, i.e. not using a pointer to an object but using a string to store something. Two examples come to mind: all the DynamicThisOrThat properties of a column in a grid - these things are evaluated - and the RemoveObject method, which doesn't use an object reference, it uses the name.
>

I see your point here. I would counter that the same thing could be accomplished with a case statement. In most cases, you only have a handful of possbilities. Coding a case statement would be a simple and effective alternative. In fact, for the sake of documentation, I would probably opt for a case statement. IMO, the more code relies on macro expansion, the less readabile and maintainable it becomes..



>Having left the compiled world long before OOP came about, I really can't figure how these things are done in a compiled language, or in a language which doesn't have an eval() function. I figure that it must use some table of published names (as COM does, specially DCOM - otherwise no scripts could instantiate objects and call their methods, not having pointers to them), but it probably has its limitations. I really have very faint ideas of how it could be done, and none whatsoever of how it is done. If it is done.
<

The simple answer is that macro expansion cannot exist in a compiled environment. But all is not lost as there are lots of alternatives. As I have said, the rest of the world has managed to get by without Macro Expansion.