Am 23.04.2018 um 02:26 schrieb Sven Littkowski:

> But what can be done about my real problem, the macro-macro situation?
> Can any fix be done?
> 
> The suggestion to call first the texture macro and only afterwards the
> object macro, would cause many, many, many more new code lines. If I can
> avoid that, I would. Sounds like an urgent patch reason to me...

Yes, actually there's a way: You can move the assignment to a variable
into the macro itself, essentially using the following construct:

    #macro MyBrownSimpleQuoVadis(...)
      ...
      #local Result =
      #switch(...)
        #case(1)
          texture { ... }
          texture { ... }
        #break
        ...
      #end

      Result
    #end

    ...

    object {
    PostsSideRailing(..., MyBrownSimpleQuoVadis(x))
    ... }

This way, the `texture{...} texture{...}` followed by `#break` doesn't
technically occur in the context of the `PostsSideRailing` macro
invocation, but rather in the context of a `#local` assignment, where it
doesn't lead to a problem. In the context of the `PostsSideRailing`
macro invocation, all that's visible is the `Return` variable
identifier, which also is unproblematic.


I guess I can't repeat this too often: When writing a macro to construct
an individual texture, object, pigment or what-have-you, it is very good
practice to first assign the thing to a local variable (which I tend to
call `Result`), and then have the macro "emit" just that variable itself.

Post a reply to this message