Macro arguments cascading into calls to other macros

0 votes
asked Dec 29, 2017 in Bug by Anthony-Gaudino (5,720 points)

If I have a macro that inserts some string containing substring X and I call this macro from another macro that receives a parameter named with the same substring X, then the X from the calling macro is cascaded into the inner macro, and replaces the X substring by the X argument.

This example illustrates the problem:

!define FOO(c, i) <color:c>i</color>

!define BAR(color) FOO(color, sometext)

class something {
    BAR(Red)
}

On the class attribute, this generates the string <Red:Red>sometext</Red> instead of the intended <color:Red>sometext</color> (which generates a red text: sometext).

This works as intended:

!define FOO(c, i) <color:c>i</color>

!define BAR(c) FOO(c, sometext)

class something {
    BAR(Red)
}

PlantUML version 1.2017.20 (Mon Dec 11 17:57:05 CET 2017)

(GPL source distribution)
Java Runtime: OpenJDK Runtime Environment
JVM: OpenJDK 64-Bit Server VM
Java Version: 9-Debian+0-9b181-4bpo91
Operating System: Linux
OS Version: 4.9.0-4-amd64
Default Encoding: UTF-8
Language: en
Country: US
Machine: Debian
PLANTUML_LIMIT_SIZE: 4096
Processors: 4
Max Memory: 826,277,888
Total Memory: 52,428,800
Free Memory: 45,253,920
Used Memory: 7,174,880
Thread Active Count: 1

The environment variable GRAPHVIZ_DOT has not been set
Dot executable is /usr/bin/dot
Dot version: dot - graphviz version 2.38.0 (20140413.2041)
Installation seems OK. File generation OK

2 Answers

0 votes
answered Jan 2, 2018 by mgrol (3,150 points)

Hi,

I don't see your point. You actually complain about the fact that a macro behaves like it should be. How should plantuml figure out that in one case you want to use this feature and in other cases you don't.

You already found your solution by yourself. In general, I use uppercase for macros so that I can distinguish between text and macros.

@startuml
!define FOO(COLOR, i) <color:COLOR>i</color>

!define BAR(COLOR) FOO(COLOR, sometext)

class something {
    BAR(Red)
}
@enduml

Best Regards,

Michael

0 votes
answered Jan 3, 2018 by plantuml (294,960 points)
Thanks for the report!
This behavior is due to the very simple way we implement our macros.
We want to mimic C-preprocessor behavior and I think that here we do not.
(BTW @Michael: many thanks to support us here :-)

I agree that argument name of the BAR macro should not interfere with <color> tag of the FOO macro.
Somehow, this breaks encapsulation of macro definition and I think that this is not how C-preprocessor works.

So we are going to fix this issue (although this is not that easy and that we do not want to break our code). We'll post a message here when ready.
In the meantime, Michael suggestion (using UPERCASED name) is a good workaround.

So thanks to both of you for your participations!
...