>> 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. >
I don't want to make us lazy by enabling to pass all information you want back to the sender of the LFUN. I also don't see why it is necessary, uptil now we only use a bool in some cases to tell whether the LFUN is processed or not. This might have been misused in some cases, but a bool has always been enough. Even in your patch, you only use one boolean. Besides, if you really need more info, then the LFUN is maybe not the best way to do it. Then you can probably call the core functions directly as this will not be of use anyway for server/minibuffer applications. >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. This is completely equivalent right ? Whether we pass a parameter object directly or whether we pass the serialized object. Vincent
