Hi Erik,

>>3. When using a VFP command window in your application, you'll have to use &.

>You can now use ExecScript for this. And in version 6, you could use FILETOSTR and COMPILE, but I suppose that's beside the point.

the EXECSCRIPT function is VFP 7 only and though a FILETOSTR in combination with COPILE and DO might also do the trick I don't think this situation is prefferable, certainly not in terms of performance.

About the exescript: I see very simular objections for EXECSCRIPT as for &. Both commands might seduce developers to write bad code.

>I guess the only reason either of these methods would be any better than & is that they aren't as fragile.

Hmmm, fragile ? What do you mean by fragile ?

>>4. EVAL and & are commands of the same family. EVAL() is more limited than & and only about twice as fast.
>
>Well, they serve difference purposes. Evaluating an expression is different than executing a command.

>> Both commands need to interpretate the argument and proces it. For both commands you'll need a runtime compiler.
>
>Are you sure about that? Not that I am disagreeing necessarily, but this is a topic I would like to know more about. EVAL doesn't have the power to run any uncompiled code, only to decide when to call a function that already exists.

Well take the following examples:

cEXpression='STRTRAN("Hello world","world","Erik")'

? &cExpression
? EVAL(expression)

Both commands need to identify whats in the string Expression, compile and execute it.

The EVAL() function is limited in executing expressions, but certainly might contain function calls and a complex AND and OR concatenation of expression.

Someone, correct me if I'm wrong, but my conclusion is that without a runtime compiler, we'll have to give up & and EVAL() as well.

>>5. both EVAL and & are very valuable in frameworks there where commands (or better: clauses of commands) depend on a given situation.
>
>This is really the situation I was asking for examples on.

Well they're numerous because there are a lot of VFP commands that don't allow name expressions as an argument. To name a few:

BROWSE FIELDS &cFields
SCAN FOR &cForclause && EVAL() solution will not be optimizable
LOCATE FOR &cForClause
ALTER TABLE Mytable &cAlterColumns


>>Though I think I know your objection against & (It attempts developers to write bad code),

>You're correct. That's the biggest reason. But not the only one.

>> I dont think this objection is true; it's application lies in the hands of the developer. I don't think that the omission of & from the language will result in less bad coding.

>I disagree. I have had to work through other developers' code where there was so much macro expansion going on, you couldn't tell what the hell was happening. Passing the name of a command as a parameter to another function is a crime worthy of punishment by troutslap. I've actually seen this and many other crimes committed using & as the weapon.

This rises the question: Do you really think these 'developers' would write better code without &. I could think of large DO CASEs or worse: IF ENDIF with unreadable structures and numerous programs without a single line of comment. Then you'll have to swim trough numerous PRGs, of long JSP structures with IF and ENDIF only to find out what is going on. With such kind of developers it does not matter how you shape the language: They'll always find some tricks to make your life miserable.

>>Personally I mainly use & for being able to add clauses to existing commands. There are numerous cases where VFP does not allow name expression and your only resort to solve the problem nice and clean (thus without long DO CASEs OR IF structures) is by using &.

>Right, but I view this not as a glorious use for &, but as a shameful workaround for big gaping holes in our language. I am of the opinion that ALL VFP commands should take named expressions instead of literals. But until then, we'll have to keep patching those holes with &.

To some extend I might agree, however as for the examples how to add additional clauses to commands (Like the alter table command) ? I don't think the VFP team would have an easy job to workarround the & here.

If the number of fields to replace in a single REPLACE command, how would you do this in a single REPLACE command with nameexpressions ?

Though I agree that & is subject to abuse in many cases. I'm convinced that in certain cases it is really helpfull as & the best and clean way to solve the problem.

Walter,