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.
On my end, I have recently had a related need: I would want to put
constraints on the method, but not for the return value, but whether the
method is allowed to be called or not.
Example:
interface Assignable
{
@Assigned(false)
void assignTo(User user);
@Assigned(true)
void unassign();
}
Where the constraint is implemented as:
public class AssignedConstraint
implements Constraint(Assigned,Assignable)
{
public boolean isValid(Assigned assigned, Assignable assignable) {...}
}
I need this in part to avoid doing these checks in the method itself,
but also to allow the client to figure out what it is allowed to do in
different states of the object. It would use the constraint syntax,
where the type is the mixin type of the entity.
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.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
