what do you think about a modification of ExecutionEngine

Hello devs,

I have been digging a bit in the code of the RTT, as I consider a small modification of the basic state transition diagram. I have found that I actually can accomplish my goals by writing user code in the updateHook() function of a subclassed TaskContext. So I can solve my problem; but I think it could be done in a nicer way.

I think it would be more elegant if ExecutionEngine would have a "UserCodeProcessor" that implements the behaviour that is currently present for user code processing, instead of hard-coding this behaviour in ExecutionEngine itself. Then, I could simply write my own UserCodeProcessor, in the same way as I can now define my own CommandProcessor.

What's your opinion on this?

what do you think about a modification of ExecutionEngine

Hi Theo,

On Friday 30 January 2009 18:06:52 t [dot] j [dot] a [dot] devries [..] ... wrote:
> Hello devs,
>
> I have been digging a bit in the code of the RTT, as I consider a small
> modification of the basic state transition diagram. I have found that I
> actually can accomplish my goals by writing user code in the updateHook()
> function of a subclassed TaskContext. So I can solve my problem; but I
> think it could be done in a nicer way.
>
> I think it would be more elegant if ExecutionEngine would have a
> "UserCodeProcessor" that implements the behaviour that is currently present
> for user code processing, instead of hard-coding this behaviour in
> ExecutionEngine itself. Then, I could simply write my own
> UserCodeProcessor, in the same way as I can now define my own
> CommandProcessor.
>
> What's your opinion on this?

You're absolutely correct. The whole 'updateHook', 'errorHook', (but also
configureHook, startHook,...) mechanism is now a hardcoded 'protocol
statemachine'[*] inside the ExecutionEngine (and partly TaskCore).

We've had discussions before that it's nice to have a default, but there's no
reason why it should be enforced on (or should be useful to) all components.

UserCodeProcessor is a close name, but UserHookProcessor is maybe better.

If you'd like to take it a step further[**], you'd need to define a
UserHookInterface or similar which declares the virtual functions that the
user must implement in his TaskContext and call that interface from
UserHookProcessor. Changing of UserHookProcessor might then lead to changing
from UserHookInterface, which gets us in pretty complex schemes. I don't know
if you wanted to go that way...

Peter

[*] Although I'm 95% ignorant, at times, I like to drop in some UML speak.
[**] YAGNI

what do you think about a modification of ExecutionEngine

On Fri, 30 Jan 2009, t [dot] j [dot] a [dot] devries [..] ... wrote:

> I have been digging a bit in the code of the RTT, as I consider a small
> modification of the basic state transition diagram. I have found that I
> actually can accomplish my goals by writing user code in the updateHook()
> function of a subclassed TaskContext. So I can solve my problem; but I
> think it could be done in a nicer way.
>
> I think it would be more elegant if ExecutionEngine would have a
> "UserCodeProcessor" that implements the behaviour that is currently
> present for user code processing, instead of hard-coding this behaviour
> in ExecutionEngine itself. Then, I could simply write my own
> UserCodeProcessor, in the same way as I can now define my own
> CommandProcessor.
>
> What's your opinion on this?

I do not get the whole picture :-) For example: how do you see the
"UserCodeProcessor" integrated with the state machine execution? I mean,
how do you define in your user code what action to do in which state? How
would you keep your user code-level state information consistent with what
the ExecutionEngine has as information about the state machine?

Best regards,

Herman

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Hmm, I must have expressed

Hmm, I must have expressed myself badly or really not understand ExecutionEngine.

Second try to explain my plan:
* For everything except for user code (startHook(), updateHook(), etc.), ExectionEngine delegates functionality to Processors: CommandProcessor, EventProcessor, ...
* the collection of TaskCores (tc that owns the engine and the children) is accessed at particular places only, where user code is called
* if you, like me, do not want to modify the main state machine, but do want to modify the logic of the user code being called during particular states/transitions, you have the choice to either try to implement that in your own subclass of TaskContext or to subclass ExecutionEngine and copy considerable parts of the code that you want reuse but cannot call separately.

To me, the solution seems to be to create a UserCodeProcessor that implements the calling of usercode (not when, but what). I have attached a modified ExecutionEngine and a UserCodeProcessor in which I try to clarify in code what I mean. Caution: this code is not complete and it has not been compiled or whatever (I do not have the facilities for that right now); it is just for clarification.

I hope that my plan is better explained now. I do not see in what way this modification causes the problems that you mention, Herman. The modification is a minor one only. Please let me know if I miss the point.

Note that it does resolve the to-do-item mentioned in ExecutionEngine.

Cheers, Theo.

Hmm, I must have expressed

On Mon, 2 Feb 2009, t [dot] j [dot] a [dot] devries [..] ... wrote:

> Hmm, I must have expressed myself badly or really not understand ExecutionEngine.

Don't worry: incomplete mutual understanding is caused by all communicating
parties, not just the sender! :-) Your further explanation now makes sense
to me :-) (And since Peter is already on it, I will not dwell on the topic
any more.)

Herman
>
> Second try to explain my plan:
> * For everything except for user code (startHook(), updateHook(), etc.), ExectionEngine delegates functionality to Processors: CommandProcessor, EventProcessor, ...
> * the collection of TaskCores (tc that owns the engine and the children) is accessed at particular places only, where user code is called
> * if you, like me, do not want to modify the main state machine, but do want to modify the logic of the user code being called during particular states/transitions, you have the choice to either try to implement that in your own subclass of TaskContext or to subclass ExecutionEngine and copy considerable parts of the code that you want reuse but cannot call separately.
>
> To me, the solution seems to be to create a UserCodeProcessor that implements the calling of usercode (not when, but what). I have attached a modified ExecutionEngine and a UserCodeProcessor in which I try to clarify in code what I mean. Caution: this code is not complete and it has not been compiled or whatever (I do not have the facilities for that right now); it is just for clarification.
>
> I hope that my plan is better explained now. I do not see in what way this modification causes the problems that you mention, Herman. The modification is a minor one only. Please let me know if I miss the point.
>
> Note that it does resolve the to-do-item mentioned in ExecutionEngine.
>
> Cheers, Theo.
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>