Quoting Rickard Öberg <[email protected]>:
On 2009-12-04 00.29, Stanislav Muhametsin wrote:
Imo Qi4j-Concerns can be both pre- and post-conditions of a method, as
it is possible to evaluate expressions before and after calling a
method, and throwing exceptions if necessary. Constraints only can
implement subset of functionality of Concerns, since they can't access
internal state nor return value.
Which is a feature!
Indeed! And a very good one, because we don't always want to expose
all our internal state to every possible check there is :)
However they are much simpler and
easier to use, and the composite doesn't NEED to have @Constraints(...)
for every constraint used in there, as it does for Concerns.
Right, so one thing to consider (which we have done before, but
which we will do again) is whether to allow declaring concern
implementation on annotations, like we do with constraint
annotations. Then it would simply be a matter of attaching an
annotation describing the condition to a method, and it will be
performed. The key issues are:
* there will be 1-1 mapping between annotation and implementation ->
hard to make semantically interesting annotations that can be used
for many things (like @Idempotent).
Counterpoint: maybe this is like the different between using
interfaces and classes. Sometimes you want abstraction and sometimes
you just want to get a particular thing done. Declaring the
implementation on the annotation *would* be optional.
* ordering of concerns is impossible. With Concerns being declared
on the composite type it is possible to list them in the order they
need to be applied.
Counterpoint: order is not always important, and using annotation
order can give some structure to it.
So, there are pro's and con's with allowing concern implementations
to be declared directly on the annotation.
Don't think I know enough about Qi4j philosophy to properly comment on
that one. :)
That would seem to be one reasonable return-value constraint. Any
others which are not better done using types?
Agreed, and for the particular case of null-checking it would make
sense. Any other cases???
Well, looking at Qi4j Constraints library, I think there pretty many
(if not all) constraints, which could be applied to method output.
@NotEmpty, @GreaterThan, etc etc. However, then it should be decided
how to handle null return values. Should the null return value be ok?
Then there would be a slight 'schizophrenia' in Qi4j, regarding null
input values and null output values. But then again, would it be too
much to make them non-null by default?
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
