Public apology. It appears I can't read!!!!!!!
A
On Tuesday 13 March 2001 16:35, John Levon wrote:
> 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
