>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.

I took data-driven case as one place which is normally achieved with use of ME, eval() or name expressions in VFP. I've gotten quite comfortable with this practice (doing that for 12 years) and can't imagine how could that be done without it. So yes, they are related, and the relation I had in mind is "data driven means using ME or equivalent".

> 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!!).

Now if that variable holds a name of the class, that's macro expansion or is it not? If not the name, then what? If it holds the class name but the class must be a COM thing (i.e. OlePublic or equivalent), that's exactly the thing which brought me the most disappointment while I was trying to use VB6 - it can't use the classes you make with it directly, you have to make them ActiveX. Either I got something completely wrong, or it sounds like "you can make a salad and the main course but not in the same restaurant". If the class-referencing variable holds a pointer to the class, then it must be compiled as a pointer to it - how do you make it point to a class whose name you calculate or bring in from a table...?

>>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.

A very long one. I'm using an integer field to hold the color of the row in a grid, as in "grid1.setall("DynamicBackColor", "alias.colorfield", "column"). This integer field can have any RGB value, which means the case statement would theoretically have 2**24 cases.

>In most cases, you only have a handful of possbilities.

Once you get into "in most cases", it means you don't have a general rule, or a general method to do something. You start writing a cookbook, one recipe after another.

>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..

Sure, the &-riddled code may be very obscure and unintelligible, but then so can be a case statement, specially once it gets beyond one screenful of lines. OTOH, I think a statement like this is quite clear:

oThing=createobject(alias.FieldWithTheClassName)

IOW, it's not the use of macros or eval() or name expressions that makes it readable or unreadable - both can be achieved in both worlds.

>>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.

I know I did while I was writing Cobol :). The question was how has it managed. My answer would be "by not using things which need ME". By having a mindset adjusted to what the language can and can not do. The same way no Foxer is comfortable with pointer arithmetic, but is comfortable with using name expressions all over the place. I figure the mindset of a C++er would be the other way around.

I'd propose a conclusion that VFP wouldn't be what it is if ME and eval() and name expressions and compiling on the fly and Dynamic* properties in a grid were removed.