Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
From: Niclas Hedhman <niclas@hedhman.org>
Date: Sat, 5 Sep 2015 15:49:46 +0800
Message-ID: 
 <CADmm+KepQgFGMwCHnab_o1UUKXtvfjf8QQqOj5hPsnTADYzPwg@mail.gmail.com>
Subject: Predicates as Constraints
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=089e0160b88ec0b045051efb43ac

--089e0160b88ec0b045051efb43ac
Content-Type: text/plain; charset=UTF-8

Gang,
ZEST-36...

I think it makes sense to get rid of the Constraint interface and use the
Predicate instead.
And at the same time support a ConstraintFactory concept, where the
Predicate can be created by a factory, to support the CompositeConstraint
concept that exists (I didn't know that).

So, something like this;

public interface Customer
{
    Property<String> name();

    @Age
    Property<Integer> age();
}

@ConstraintDeclaration
@Retention( RUNTIME )
@Constraints( AgePredicate.class )
public @interface Age
{
    int min() default 18;
    int max() default 95;
}

public static class AgePredicate
    implements Predicate<Integer>
{
    private Age range;

    @Override
    public boolean test( Integer argument )
    {
        return argument > range.min() && argument < range.max();
    }
}

I will think a little bit more about the ConstrainFactory, but it should
probably get access to a bit more than just the Annotation.

To make the codebase lean, I would like to remove the Constraint variant
completely, although @Constraints remain as previously.

WDYT?

Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--089e0160b88ec0b045051efb43ac--