>Peter,
>
>I didn't get answers to both of my question, so I assume that you have nothing to say and I consider this discussion closed.

Sergey,

You've possibly not read my reaction to your 'hah?' question. E.g., look at how number 2 of the 2nd list is now formulated. If that formulation doesn't incorporate your critizism, then tell me, ok?

And I also reacted on your 'examples' question. In another message I asked you to provide examples of bad readability and - even more important - badly maintainable code. You claimed to have had nightmares, and I'm curious to see some examples, really.

Although I too have the feeling that this discussion is somewhere at its end, I'd like to end it with some sensible conclusions. We're almost there, but especcially the maintenance issue remains to be settled.


>>[snip]
>>>
>>>>2) A macro occasionally improves readabillity.
>>>>3) A macro occasionally improves code maintenance.
>>>
>>>Never seen such situation. Can you provide some examples?
>>
>>I asked first Sergey. :)
>>Remember the other message (Thread #735756 Message #736197) where I invited you to provide examples of bad readability and maintenance.
>
>
>>
>>
>>[snip]
>>>
>>>>2) Macros are only the second to best way to parametrize a name expression in a command.
>>>
>>>Hah? Why would you want parameterize name expression? If name expression can be used than why would you need macro substitution?
>>
>>I guess that native English speakers have an advantage here?! Or am I only one of the few who got confused? Give me a second chance:
>>
>>There's another item that needs to be mentioned here: 'Name expressions'. This is a phrase that's used in the help text to refer to variables that can be used in commands/functions to specify a name, e.g. the name of a file, alias, table or field. Often it's okay to hardcode the name without the use of quotes. If you need to use a variable, it's necessary to prevent that the actual name of the variable is used as name. The preferred way to prevent that is to enclose the variable in parentheses, rather than use macro substitution. An enclosed variable in parenthesis is called a 'name expression'. The mentioned reason is speed. Other reasons may be thought of, but there's no heavy penalty for those who want to use macro substitution instead.
>>In the macro help text 'keywords' of commands are also mentioned. Their advice is: Whenever you want to parametrize a keyword of a command, use a macro. Name expression and eval() are not mentioned for that case.
>>In the evaluate() help text, the advice is to use eval() or name expressions instead of a macro, whenever possible. The only mentioned reason is, once more, speed. On the other hand, it's stated also that eval() is not rushmore optimizable. I found out that a SQL-query with a built-in macro is potentially still rushmore optimizable, since the optimization decision is made only after the one-time evaluation.
>>
>>I still stick to this list:
>>1) A macro occasionally gives better performance (speed) than eval().
>>2) A macro occasionally improves readabillity.
>>3) A macro occasionally improves code maintenance.
>>4) A macro occasionally is the only way to accomplish a task.
>>
>>But maybe you like this list more:
>>1) Macros are the only way to parametrize a keyword in a command.
>>2) Name expressions are the best way to parametrize a name requirement in a command. Macros are only the second to best way for this.
>>3) When used as argument in a loop construction (like a DO WHILE and a SQL-query), there's a fundamental difference in the way that a macro and an evaluate() are handled. The functional requirement is therefore decisive.
>>4) Evaluate() is not Rushmore optimizable, whereas the use of a macro leaves that possibility intact.
>>
>>[snip]