Andre Poenitz wrote:
And right now I start to get the impression that we a close to one of
our good old attempts to abstract where abstraction isn't called for.
To play the devil's advocate: What would be wrong with
virtual string InsetCommand::parametersToString() const;
and
virtual void InsetCommand::parametersFromString(string const &);
with suitable implementations in all derived classes? Common code
could be put as helper method into InsetCommand.
Maybe I'd be even worth to generalize those at Inset level (using
docstring):
virtual docstring Inset::toString() const;
virtual void Inset::toString(docstring const &);
What exactly is InsetCommandParameter used for?
Inset construction from a string?
-> We can construct an 'empty' isnet and call parametersFromString() on it.
Storing temporary copies in the dialogs?
-> Store a stringified version there. We convert it to a string anyway
when dispatching.
No matter what he says I wonder whether the dispute is on the right
level. I question I see is whether InsetCommandParams is the right thing
to use (a) in this case, and (b) in general.
Note that it original structure was just a convenient way to pass two or
three data items typically associated with a simple LaTeX commands
around. Nowadays it looks like a ton of bureaucracy sparking three-week
discussions...
Andre' seems to have a point here... Long discussions often means that
some designs needs to be changed :-)
Abdel.
