This is a remark about how is working delegators in OpenCOM 1.3.
When adding a pre method, its signature has to be (int (*)(String, Object[]) because, the result of a pre method is 0 if it is ok or else if it is not.
When adding a post method, its signature has to be
(result type of the method or int (*)(String name of the method, Object[] result+args).
I see 2 mains issues of the post method:
- firstly, if the result is an integer different of 0, and the post method modifies the result with another value different of 0, then this is the old result which is returned, not the modified one.
- secondly, if the invocation throws an exception, this exception can not be treated by the post method, which, I mean, should play this part.
What is your opinion?
Thomas Pareaud
Phd at LAAS-Cnrs in France
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with the comments here. There is certainly room for improvement in the post method programming model. For, the individual comments:
1) This is a bug; however rather than fixing it I may replace the post method syntax to attempt to improve the programming model. My idea is to pass the original result of the operation as a separate parameter and the post method returns a value that is always the final result - hence if there is no change it passes the original result e.g.
(result type of the method (*)(String name of the method, Object result, Object[] args){return result;}
2) The pre and post methods were not originally designed (hence not implemented) to deal with this style of error handling. However, I agree that the ability to hand on the exception to the post method provides the ability to separate exception handling from the business logic. At the moment, the exception breaks and misses the post method which in some cases is not desired behaviour. I'll try and think of a good way to maintain a correct flow, and pass the exception information to the method. If anyone has ideas how to do this let me know.
Paul Grace
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion, there is no easy way to nicely wrap calls of interfaces (because, I think that what we are doing by using pre/post calls is wrapping, isn't it ?).
This work need a global reflexion on what exactly pre/post methods stand for, ie. why these methods? and what is wanted to do with them? (ie. at the meta level, what is the use of the interception mechanisms?)
The answers will probably lead to the programming solution of the interception in the OpenCOM framework!
For example:
if the answer is, we just want to know that a method is called, then, the solution is just create an event on call.
if the answer is, we want to verify global properties on several components before allowing a call and verify that the result verifies other global properties, with the possibility of launching error handling action, etc, then the solution becomes, in my opinion, much more complex... but also more interesting from the meta-level point of view!
Thomas Pareaud
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
This is a remark about how is working delegators in OpenCOM 1.3.
When adding a pre method, its signature has to be (int (*)(String, Object[]) because, the result of a pre method is 0 if it is ok or else if it is not.
When adding a post method, its signature has to be
(result type of the method or int (*)(String name of the method, Object[] result+args).
I see 2 mains issues of the post method:
- firstly, if the result is an integer different of 0, and the post method modifies the result with another value different of 0, then this is the old result which is returned, not the modified one.
- secondly, if the invocation throws an exception, this exception can not be treated by the post method, which, I mean, should play this part.
What is your opinion?
Thomas Pareaud
Phd at LAAS-Cnrs in France
Hi,
I agree with the comments here. There is certainly room for improvement in the post method programming model. For, the individual comments:
1) This is a bug; however rather than fixing it I may replace the post method syntax to attempt to improve the programming model. My idea is to pass the original result of the operation as a separate parameter and the post method returns a value that is always the final result - hence if there is no change it passes the original result e.g.
(result type of the method (*)(String name of the method, Object result, Object[] args){return result;}
2) The pre and post methods were not originally designed (hence not implemented) to deal with this style of error handling. However, I agree that the ability to hand on the exception to the post method provides the ability to separate exception handling from the business logic. At the moment, the exception breaks and misses the post method which in some cases is not desired behaviour. I'll try and think of a good way to maintain a correct flow, and pass the exception information to the method. If anyone has ideas how to do this let me know.
Paul Grace
Hi,
In my opinion, there is no easy way to nicely wrap calls of interfaces (because, I think that what we are doing by using pre/post calls is wrapping, isn't it ?).
This work need a global reflexion on what exactly pre/post methods stand for, ie. why these methods? and what is wanted to do with them? (ie. at the meta level, what is the use of the interception mechanisms?)
The answers will probably lead to the programming solution of the interception in the OpenCOM framework!
For example:
if the answer is, we just want to know that a method is called, then, the solution is just create an event on call.
if the answer is, we want to verify global properties on several components before allowing a call and verify that the result verifies other global properties, with the possibility of launching error handling action, etc, then the solution becomes, in my opinion, much more complex... but also more interesting from the meta-level point of view!
Thomas Pareaud