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!
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.
So from pre/post -condition perspective, Qi4j is a little fragmented as
Constraints can be used for certain part of pre-condition functionality
(performing static checks for input parameters), and Concerns can be
used for ALL pre/post -condition functionality (can evaluate any
expression, as it has access to internal state).
No, Constraints cannot be used for pre-conditions at all, since
pre-conditions are about system state. Concerns is what you want!
@Identifier
String identifyNextToken();
Hmm, depends what you mean by @Identifier. If it can be done without
internal state checking, then sure.
But wouldn't it make more sense to use types for that:
Identifier identifyNextToken();
I had something like this in my mind:
@NonNullResult
String identifyNextToken();
Now, whoever uses identifyNextToken() method, can always assume that the
result he gets from this method is always non-null, as it will be
ensured by the framework (assuming the composite doesn't override
default implementation).
That would seem to be one reasonable return-value constraint. Any others
which are not better done using types?
Imo in all bug scenarios, the sooner the bug is noticed, the better.
Suppose there is an internal error in codebase, and it returns some
illegal value. Then we store it in some object for a while, and at some
point, use it, or even worse, pass it on somewhere else. So either bug
can be detected there, or it stays hidden until something actually uses
the value. And by then, it will be hard to track (in any non-simple
application).
Agreed, and for the particular case of null-checking it would make
sense. Any other cases???
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
