[hibernate-dev] [HV] Design philosophy

[Hardy Ferentschik]

On Apr 11, 2012, at 10:52 AM, Emmanuel Bernard wrote:

> When adding a feature, we have always implicitly asked ourselves this pool of questions:
> 
> 1. Does it feel like the right way of doing things?
>    If it's not, we have been prone to wait till we mature on the idea. Take collection element constraints as a good example. We know the right way but
>    it's not available to us yet
> 2. Can I do it with an existing construct with similar or less complexity?
> 3. Is this feature wrong? eg validating unicity with a database query is wrong.
> 4. Is this a popular request? 
> 5. Is this feature useful in the general scheme? "What's your use case?" mantra.
> 6. Is it the most readable approach?
> 7. Is the feature designed consistently with the rest of the library

+1 agreed

> Keeping the library useful and simple is a constant battle against people wanting to throw new features at it but resisting to the dark side is
> important. More than that, I think that's our job to be this gate keeper and we deserve to be shot in the knee and kicked while on the ground.
> We are here to make the world a better place, not give food to guideline writers.

+1 I more than once resisted the dark side 

> If we go back to our example, @Email(regexp=""^((?!\\.org).)*$") is not really 5 nor even 2 times better than @Email @Pattern((regexp=""^((?!\\.org).)*$")

I am not sure how one would measure this leverage factor so I stay out of it. Adding the regexp is backwards compatible, its optional and hence for most users
not visible. If you are going to need it you have the choice between:

@Email(regexp=""^((?!\\.org).)*$") 

or 

@Email 
@Pattern((regexp=""^((?!\\.org).)*$")

I don't see any harm here. In fact I think that the first version even adds a little more context information, because it tells me that the main concern is about making sure 
that we have an email (meeting an additional validation criteria). In the second case the @Pattern could also be just replacing a @NotEmpty (depending on the 
regular expression of course) constraint.

> And frankly, regexp is about the less readable construct in the history of programming languages.

and one of the most powerful one as well :-) 

> I am not against some functional flags to
> restrict the domain, ensure that it's an email address reachable from the internet etc etc

I am not against additional flags either, and I was in fact thinking whether a "reachable" flag to @Email and @URL would make sense. This is something which is outside
the character based validation. Regarding the domain restriction flag, where do you draw the line? Do you want a includeDomain, excludeDomain, includeUser, excludeUser, allowGmail, disallowYahoo, … - or do you rather add a regexp flag?

--Hardy