Quoting Rickard Öberg <[email protected]>:
On 2010-01-18 04.38, Niclas Hedhman wrote:
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.
Ahh! No, Concerns are allowed to modify return values. And this raises
a problem.
If the post-constraint contract is "for the composite", we would need
to execute "after" the method is completed, BUT if there then is a
violation, wrapping concerns should probably know about it. So, by the
sounds of it, it needs to sit "in between" different concerns. Perhaps
it is possible to implement the whole concept with Concerns and clever
use of the Invocation annotation, meaning it would be a library
separated from Core.
Hm.. to me it sounds more reasonable if this check is done (if at
all) after the concerns are executed (=return value is determined),
but before sideeffects run.
Now that I think about it, I agree.
[...]
If this is done then syntactically it would clash with the return
value constraints. And for my purposes, if only one of them can be
done, I would prefer the above since it's not just "would be nice to
have", but actually gives something to my system at runtime.
If there was a way to do both, that would be interesting too though.
Okay, so seems we have three types of constraints:
1. On input parameters
2. On method return value
3. On actual invokation logic of method
One idea could make three different of types of Constraint-classes,
one for each of type of constraint. It would make things clear for
compiler (from what I know / remember of Qi4j implementation), however
for humans it still might appear confusing / ambiguous / hard to read.
Maybe for each constraint, placed outside method's parameter list,
could do something like this:
@Optional(target=ReturnValue) @Assigned(target=Composite)
void assignTo(User user);
How about that kind of syntax?
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
