[fpc-devel] Macro Processing

[Martin]

On 16/05/2011 10:23, Joerg Schuelke wrote:
>
> My debug system gives me what I want:
> - FILE info from build-in macro
> - FUNC info from build-in macro (patched by myself)
> - LINE info from build-in macro
> - the additional info I request
>
> And now it is time to say that a real discussion is not possible if you
> always say: Yeah, you should not do that! Sounds like religion for me.
>

IMHO a discussion on this is limited by the fact that the importance all 
of the reasones (pro and contra) is very subjective.

In short, it is possible to do any of this without (further) macros) 
That is i believe agreed. It is merely a question of how much extra typing.

- The log stuff can be done by inserting $I %FILE& in every call to the 
log; and by using $IFDEF a lot. Though there are tricks to reduce that...
- The array of callbacks can be maintained with find-and-replace (does 
not need an IDE)
- worst case some pascal code can be generated by another 
application/script and be included (the generated file would never be 
edited directly (like translated header files)

1) Anyway, a macro can save some typing, make some block of code 
shorter, reduce the need of repeating something (well replace it by 
repeat the macro)

2) But a macro also weakens the fundamental concept of how a language is 
defined. A macro allows you do define a new syntax. To create something, 
that other do not know how to read. Using a macro *can* be seen as 
saying, the means provided by the language you choose are not good 
enough, so you need something else (raises the question why you choose 
that language).

Both lists can be extended. But never mind if each list has 1 or 2, or a 
hundred entries. You have to decide personally what is more important to 
you.

Those who studied the concept of designing a language (which is 
apparently a huge topic), may be able to add some (more) objective 
reasons. But for the rest of us this comparison is a subjective task.
Highly influenced by what each individual, wants to do, and is used to 
do from past experienced.

Obviously for you the gains, are more important.
But same as obviously for other the losses (readability, compromising 
language design) are important too.

So far each side has repetitively pointed out, that in their opinion, 
their arguments are more important (that does not make the arguments of 
the other side wrong, it simple indicates the personal importance of them).



As for no one is forced to use it....
Not entirely true. Only if I write code, that no one else can ever 
change. Lots of code is written n teams. Lo9ts of code (especially open 
source) code uses 3rd party packages, and may require to read that code.
Once the feature is available, **everyone** who has to read such code, 
must always look at for it.
Making the feature available, forces others to deal with it.