On Tue, 13 Mar 2001, Angus Leeming wrote:
> On Tuesday 13 March 2001 16:01, John Levon wrote:
> > Can I just point out I didn't *add* this, I simply moved it - it was already
> > a member of insetinclude.C
>
> I know. But you're only doing this so that you can pass/store an InsetCommand
> to FormInclude.
>
> I don't think that we should rush getting xforms out of the core if it
> produces "bad" side effects. If you want information in FormInclude from an
> InsetInclude that isn't in an InsetCommand, then you should pass an
> InsetInclude. Simple as that.
Why ? I could apply the same argument to all of the "pass-a-params" forms,
why do they all have a local copy of the params that they modify then
set on the way back ? The answer is it seems cleaner (I assume this is why it
was done). Of course it is slightly different there because there is an inheritance
heirarchy.
And I don't like the suggestion I am making the core worse with any changes I do.
The patch review process is exactly for you and others to catch any dumb mistakes
I make ...
I asked you how to do this before I wrote the new version, and you basically suggested
to do have an InsetIncludeParams. Why have you changed your mind ?
So you're saying I should abandon any params passing at all right, and just modify
the inset directly at apply() time ?
> getBuffer()
I personally would much prefer to keep the InsetIncludeParams, except for the buffer
parameter, and call inset_->getBuffer()->fileName() in the relevant part in
FormInclude.
What's wrong with that plan ?
john
--
"To be fair i do look quite like a monkey ..."
- Peter Reid
