rgheck wrote:
This particular version seems unnecessarily complex. FuncRequest
should just have a DispatchResult member. The pointer member is asking
for trouble, I think.
AFAICS, what is returned by an LFUN may be LFUN dependent. So we have
two options:
1) use the string-encoded return mechanism, similarly to the current
LFUN argument passing (personally disliked);
2) use a basic DispatchResult class with proper subclasses which are
LFUN dependent. The caller of an LFUN knows what exact type to expect in
return, so a proper DispatchResult subclass may be instantiated and
supplied into the loop. Also, when the LFUN is intercepted, its
implementation knows what exact type was supplied by the caller, so it
can dynamic/static_cast<>() and properly fill the return value. This
cannot be achieved with a simple DispatchResult member (unless you want
to use a big union of all possible return values).
If it were for me, I would also turn the LFUN argument passing mechanism
from the string-encoded way it is now to the 2) point described above.
The string-encoding stuff is something related to the dispatch of LFUNs
from the mini-shell, but that may be achieved (orthogonally) by proper
deserialization of LFUN arguments from their string-encoded version the
user is supposed to type.
my 2 cents.
T.
