OK, it's been a while and I've been awfully busy, but now I've put up
a proposition for "post-constraints", which were discussed in December
2009.
1. What?
Post-constraint is a constraint, applied to a result of a non-void method.
2. Why (Motivation)?
To detect the bugs as early as possible, and thus produce more
reliable applications. To have an easy way to express the outcome of
some method, to specify more than just a type - it is part of
interface definition as much as constraining input parameters.
Also all or most of the current constraints in the constraint library
of Qi4j can be thought to be applied on return values too, so why not,
if developer wants to?
3. Why not (Motivation against)?
Possible overhead (due to extra checking). Possible syntax-confusions
(see below).
4. How?
Keep Constraint -interface as it is. Mark the methods with
constraint-annotation as with concerns (hence the possible
syntax-confusions).
All methods must by default return non-null value, same as with method
parameters.
If the method has concerns or side-effects, post-constraint should be
executed before returning back to concern and (therefore) before
executing side-effect. It makes more sense with this + concern can't
modify the result of the method in between.
If the overhead of these is too much, there could be added some kind
of "usePostConstraints" -switch to Qi4j runtime.
5. Something else?
Probably there is something else that I am forgetting right now or
didn't think of. Any input?
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
