OutputParams

[Richard Kimberly Heck]

On 11/2/20 1:36 PM, Yuriy Skalko wrote:
>> That is fine. I do prefer this initialization syntax.
>
> Committed.
>
>> Good luck with the rest! It's a minefield.
>>
>> Riki
>
> Riki, have you seen my last patch? I hope this minefield is walked 
> through without significant losses :)

Yes, I looked at it but didn't have time then to comment.

It's fine as far as it goes, but I was thinking something somewhat 
different. Others can chime in, perhaps, but I think there's a reason 
that OutputParams was always supposed to be passed as const. At least, 
it began life as precisely what it sounds like: A bunch of parameters 
that give us information about what we're supposed to output. These, one 
might imagine, would be set once and for all when the output routines we 
launched.

But then, I think, OutputParams grew into a somewhat different beast: A 
collection of flags that affect output and that can be set and reset 
during the output process. In a way, that's not so difficult: We can 
copy the OutputParams to some temporary object, change them as needed, 
and pass the temporary down the chain. This gets done quite a lot, in 
fact. But then it gets worse: Sometimes, the lower down routines make 
their own changes, which need to be propogated *back up* the chain. So 
now the temporary object solution doesn't really work.

So, one option, indeed, is to forego the pretense that OutputParams is 
const and just pass a reference everywhere. That's what your patch does. 
The other, which is what I was trying to do some time ago, is to 
untangle this mess, especially the back-propogation of flags from the 
lower down subroutines. Making all those things mutable was a hack-ish 
solution.

A start on fixing this would be to figure out which things really do 
need to be back-propogated and which things don't, and make only the 
former mutable, and force changes to the latter to be done with a 
temporary object. Whether it's all worth doing isn't entirely clear to me.

Riki