polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Muhametsin <stanislav.muhamet...@zest.mail.kapsi.fi>
Subject Re: Predicates as Constraints
Date Mon, 07 Sep 2015 09:22:12 GMT
On 7.9.2015 11:46, Niclas Hedhman wrote:
> The value in the annotation is solved by field/constructor injection and is
> not an issue (I think).

Currently in Zest, (AFAIK) the constraints can't have any injections.
That is IIRC because they are not managed from composite-wide instance 
pools (since some injections require 'taking ownership' of the fragment, 
since they are not thread-safe, or value varies depending on which 
composite instance is currently using fragment).

The same goes for Qi4CS: constraint instances are pooled on whole 
application level.
If you guys get to implement this without running into any issues or 
problems, I might do the same in Qi4CS as well.
Been thinking about this for a while, and allowing injections on 
constraints as well would make things nicely symmetric and orthogonal, 
since now constraints are a little 'special snowflakes' in Zest/Qi4CS 

> On Sep 7, 2015 16:41, "Paul Merlin" <paul@nosphere.org> 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

View raw message