The value in the annotation is solved by field/constructor injection and is
not an issue (I think).
On Sep 7, 2015 16:41, "Paul Merlin" <[email protected]> wrote:
> Niclas,
>
> Just some thoughts ...
>
> Niclas Hedhman a écrit :
> > Thinking a little bit outside our current box....
> >
> > public interface Abc
> > {
> > void doSomething( @URL String url );
> > }
> >
> > module.values( Abc.class ).for( URL.class ).constrainWith( url ->
> > checkUrlFormat(url) );
> > module.for( URL.class ).constrainWith( new UrlChecker() );
> >
> > I have started to experiment a little around this... More follows later.
> >
> > Ok, after digging in this for an hour or so, I have discovered more
> > features...
> >
> > The above is the default implementation, and it is then possible to throw
> > other implementations at the composite, and in that way override the
> > Constraint check declared in the annotation. There is also the Composite
> > Constraint feature (which I want to replace with factory instead)
> >
> > The mechanism uses the fact that the Constraint implementation contains
> the
> > Annotation type as a generics argument, and that is how they are matched.
> > IF I go with Predicate, there is no such possibility, unless the
> Predicate
> > itself is annotated (I think not so nice).
>
> Having a handle to the annotation in constraint implementations also
> allow access to values of the constraint annotation parameters. Eg.
> @Min( 3 ).
>
> > So, the immediate question is; How desirable is this "override" feature?
> Is
> > there any other way to achieve the same functionality?
>
> I understand this "override" feature as "changing the constraint
> implementation referenced by a constraint annotation at assembly time".
> I have no usecase in mind.
>
> /Paul
>
>
