Stanislav, What Rickard is discussing is that for Constraints it is possible to declare on the constraint annotation itself which implementation it should be, OR declare them on the Composite like Concerns. He is arguing for and against whether to allow the same pattern for Concerns, which I think in many cases makes sense, for instance @UnitOfWorkPropagation.
-- Niclas On 4 Dec 2009 11:30, "Rickard Öberg" <[email protected]> wrote: On 2009-12-04 00.29, Stanislav Muhametsin wrote: > > Imo Qi4j-Concerns can be both pre- and post-con... Which is a feature! > However they are much simpler and > easier to use, and the composite doesn't NEED to have @Const... 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 use... 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 ... 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, ... 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 inter... Agreed, and for the particular case of null-checking it would make sense. Any other cases??? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] htt...
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
