On 2010-01-18 12.53, Stanislav Muhametsin wrote:
[...]
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
Exactly. All are important, and all are awkward to do without explicit
support for it, IMO.
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.
One problem is that I don't think there's really any difference between
them, with regard to the implementation. The Constraint interface covers
them all. I suppose what we could do is have different annotations on
the annotations, i.e.
@ConstraintDeclaration
@Retention( RetentionPolicy.RUNTIME )
@Constraints( MaxLengthConstraint.class )
public @interface MaxLength
{
int value();
}
for parameters and returnvalues, and then:
@MethodConstraintDeclaration
@Retention( RetentionPolicy.RUNTIME )
@Constraints( AssignedConstraint.class )
public @interface Assigned
{
boolean value();
}
Which would lead to:
@Optional @Assigned(false)
void assignTo(User user);
where @Optional refers to return-value (as it doesn't make sense to say
"Optional" on the method), and @Assigned is clearly for the method, and
yet the implementation AssignedConstraint simply implements
Constraint<Assigned,Assignable>.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
