[hibernate-dev] [HV] Design philosophy
Hi all,
Hardy, Gunnar and I started a discussion that is worth more Eyeballs.
It started after the addition of a `regexp` attribute on @Email to be able to restrict the
shape of the email via an extra regexp.
Here is the exchange
Emmanuel:
I don't understand. Is this feature different than
@Email @Pattern("regexp")
If that's different I have not found how. If it's not I don't see the point
in adding complexity to @Email.
Hardy:
The difference is that you only have a single annotation. Internally you are using
composing constraints (so not really adding much complexity)
and report as single violation (which is probably where the advantage lies).
It is probably a matter of taste whether you prefer a single @email annotation or @email
and @pattern.
Emmanuel:
Also it makes for much less readable code which is something we have constantly
discouraged.
What reads better @Email(regexp="^((?!\\.org).)*$") or
@SomeEmail(excludeTld="org"). Granted, one need to write
an custom annotation but readability is much different. I leave it as an exercise to
write the same samples if 5 TLDs
need to be excluded :)
Hardy:
@email(regexp="^((?!\.org).)*$")
You must admit, this is a little bit of a special case. I stumbled across this when
looking for negating regexp.
Granted, one need to write an custom annotation but readability is much different.
in this particular case you might be better off w/ a custom constraint. A more common use
case would be to restrict to your
own subdomain
Gunnar:
I think we're basically offering users several options/styles here from which they
may chose the one they like best.
I see use cases where a custom constraint isn't worth the efforts and having the
additional pattern restriction within the
@Email constraint might be preferable over expressing it via a separate @Pattern
constraint.
It's also a good thing IMO to be consistent with @URL where we have a regexp()
attribute as well (see HV-406).
To reply to this thread and in particular Gunnar, let me expand a bit. Hibernate Validator
and to a certain extend other Hibernate projects
have been designed to improve developer productivity not improve choice of style. Choice
of style is an important reason why the Java
web stack is so complex to build an application. I don't want to be responsible for
adding garbage.
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
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.
If we go back to our example, @Email(regexp=""^((?!\\.org).)*$") is not
really 5 nor even 2 times better than @Email
@Pattern((regexp=""^((?!\\.org).)*$")
And frankly, regexp is about the less readable construct in the history of programming
languages. I am not against some functional flags to
restrict the domain, ensure that it's an email address reachable from the internet etc
etc as this can be made very readable and clearly
adds over a mix of @Email + @Pattern. And I also dislike @URL.regexp for the same
reasons.