Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, Oct 11, 2003 at 02:43:39PM +0200, Lars Gullik Bj�nnes wrote:
>>
>> Please have a look.
>
| Fine with me with exception of the
>
| - virtual dispatch_result localDispatch(FuncRequest const & cmd);
| - ///
| /// Get the inset parameters, used by the GUIndependent dialog.
| InsetGraphicsParams const & params() const;
>
| +protected:
| + ///
| + virtual
| + dispatch_result
| + priv_dispatch(FuncRequest const & cmd, idx_type &, pos_type &);
>
| stuff.
>
| I'd rather put the idx_type and pos_type argument in the FuncRequst
| too, and use
Well... FuncRequest are over-fat already.
(The actuall lfun and arg should have their own object, all the other
vars are just convenience.)
>
| 'virtual dispatch_result dispatch(FuncRequest & cmd);'
>
| or, if you don't like that at all
>
| 'virtual void dispatch(FuncRequest const & cmd, FuncResult & res);'
>
| with FuncResult being
>
| struct FuncResult {
| dispatch_result res;
| idx_type idx;
| pos_type pos;
| };
Are you sure that no dispatch ever uses the idx and pos passed in?
Then I'd rather make the dispatch functions return a complex object
FuncResult, than passing it in.
| The reason is that we'd most likely have to add a third item soonish to
| model 'Parlist/Paragraph/Position' of InsetTabular and I do not want to
| touch all headers again. And it is less clutter...
I have no problem with that, so ask me to do it when the time arises.
I'l continue to do monotonic improvements anyway.
(The return of FuncResult f.ex., which actually fit rather well with
my plans for dispatch.)
--
Lgb
