OutputParams refactoring

[Yuriy Skalko]

> I started a patch some time ago trying something like that method for OutputParams generally. The destuctor for the new instance copied relevant changes back to the one one. Basically something like:
> 
> 
> class NewOutputParams : public OutputParams {
>     explicit NewOutputParams(OutputParams & oldop)
>         { oldop_ = oldop; }
>     ~NewOutputParams()
>         {
>             oldop_.is_child = is_child;
>             // do the same thing for other currently mutable members
>         }
>         private:
>         OutputParams oldop_;
> }
> 
> In that case, though, it didn't solve the problem of mutable members. Yuriy's idea of separating the two parts takes care of that problem, and then changers could be used as you suggest.
> 
> 
> Riki

Yes, RefChanger is an interesting approach, it will be better than stack.

This NewOutputParams class looks like variation of the RefChanger. Right?


I understand how RefChanger works, but Changer is a strange thing. How 
can it work with empty functions? And why Revertible definition is 
called forward declaration? Am I miss something?

> // Forward declaration for support/RefChanger.h
> struct Revertible {
> 	virtual ~Revertible() {}
> 	virtual void revert() {}
> 	virtual void keep() {}
> };
> using Changer = unique_ptr<Revertible>;


P.S. I've tried to search for some docs on Changers in LyX repository 
and found this useful document: 
development/coding/CodingRulesAndAdvice.lyx. Maybe it will be reasonable 
to merge it into lib/doc/Development.lyx so that developer documentation 
will be in one place?


Yuriy