rgheck ha scritto:
On 08/30/2009 07:26 AM, Vincent van Ravesteijn wrote:
Tommaso Cucinotta schreef:
Is there any clean way to return something from the LFUN dispatch
mechanism ?
Explaining: I'd like to have a LFUN with a sort of return value, so
that I can dispatch an LFUN from the GUI, then check some return value.
If I wanted to do something like this, I'd adapt DispatchResult.
From the class name, it seems to be exactly what I would need. However,
this is the current situation:
src/Buffer.h: void dispatch(std::string const & command,
DispatchResult & result);
src/Buffer.h: void dispatch(FuncRequest const & func, DispatchResult
& result);
src/BufferView.h: bool dispatch(FuncRequest const & argument);
src/Cursor.h: void dispatch(FuncRequest const & cmd);
src/Cursor.h: DispatchResult result() const;
src/Cursor.h: DispatchResult disp_;
src/LyXFunc.h: void dispatch(FuncRequest const &);
src/LyXFunc.h:extern void dispatch(FuncRequest const & action);
src/LyX.h: friend void dispatch(FuncRequest const & action);
src/Text.h: void dispatch(Cursor & cur, FuncRequest & cmd);
Basically, only Buffer::dispatch() supports the DispatchResult output
argument, and Cursor::dispatch() seems to have some awareness of the
DispatchResult, but with a different interface (instead of having the
second output argument to the dispatch() method, I see this result()
method).
So, I would have a couple of questions:
1) would it be something so bad, to:
a. remove the "const" specifier to the FuncRequest argument in the
set of (all) dispatch() methods
b. adding some fields to the FuncRequest itself (for example,
DispatchResult could be a field of FuncRequest)
c. letting the LFUN implementations provide some "response data" to
the caller, by setting these additional fields (possibly altering the
DispatchResult contents)
2) alternatively, would it be something so bad, to (seems more coherent
with current design):
a. add a "DispatchResult & dr" argument to all the dispatch()
methods, leaving the FuncRequest as const, as it is now
b. letting the LFUN implementations provide some "response data" to
the caller, by setting some fields within the DispathResult object
3) would it be an error to subclass from DispatchResult ? and what about
subclassing from FuncRequest ? It would allow for a type-oriented
passing of parameters from/to LFUN implementations, as opposed to the
current string-encoded approach -- of course, one could still be forced
to provide << and >> operators in order to easily serialize/deserialize
FuncRequest and DispatchResult objects and keep the mini-buffer
string-oriented invocation of LFUNs. Also, in those cases in which
serialization of LFUN parameters is not strictly necessary (i.e., call
from GUI to model), it would be possible to avoid the string-encoding at
all.
Thanks, bye,
Tommaso
