Re: [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. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev