>Peter,
>
>>There are more than enough situations where speed isn't an issue at all, for example if it's not in a million times loop. Even in a SQL-query it's okay, as the substitution is done only once by vfp.
>
>In SQL-query it's okey because VFP doesn't offer any other way to build and execute dynamic queries.
>
>>Harder to read? Which one is harder to read? I can't see an essential difference.
>>

>>&lcString = &lcDir
>>STORE EVALUATE(lcDir) TO (lcString)
>>

>
>The first line (with macro substitution) imposible to decode w/o knowing values of both variables because variables in macro substitution can include any valid code.
>The second line (w/o macro substitution) is clear, value of 'lcDir' expression is stored into variable/property represented by 'lcString' value.

Hi Sergey,
What do you mean with 'decode' here?

>>Maintenance issue? Tell me...
>
>If you've something to say, say it. I supported enough code written by other programmers with unnecessary macro substitution to know what a nightmare it is.

No really, I'm interested in examples. Sure, I have my standpoint, but I'm eager to learn of examples that partly or wholy falsify my standpoint.

>>
>>The core point is that AndersH may have (had) a feeling that macro substitution is not a proper programming technique. Statements about performance penalties have been abundant in the last decade and still have their impact on many programmers. I challenge those judgments and think that they're obsolete.
>
>My point is, that there is no reason to use macro substitution if code can be written w/o it.