There's are 400 lines of "general" read/write infrastructure plus three
extra static methods per inset that in the end achieve something pretty
similar to

        void InsetMathSqrt::write(WriteStream & os) const
        {
                os << "\\sqrt{" << cell(0) << '}';
        }

        void Parser::parse1(InsetMathGrid & grid, unsigned flags,
                const mode_type mode, const bool numbered)
        {
                [...]
                else if (t.cs() == "sqrt") { [...]
                                cell->push_back(MathAtom(new InsetMathSqrt));
parse(cell->back().nucleus()->cell(0), FLAG_ITEM, mode);
                }
                [...]
        }

i.e. in each class derived from InsetCommand there is already more code
needed just to _interface_ the "nice general" code in InsetCommandParams
than an inset specific read/write implemention would take. This is
cancer that should not be allowed to grow any further.
Where is all this extra code in, say, InsetHyperlink? I don't see it. It doesn't even have its own write() or read() method. Same for InsetLabel. Same for more of them. There is messy interface code in InsetBibtex, yes. I'll give you that one. But that will be there anyway, I suspect.

Anyway, I'm not insisting upon converting InsetGraphicsParam. If the patch makes things worse, we shouldn't do it, obviously. I won't know that until I look more closely. But if it loses 200 lines of code, I suspect that will make you happy. ;-)

rh

Reply via email to