[hibernate-dev] [HV] Design philosophy

[Emmanuel Bernard]

BTW I don't know when the properties have been added to URL, but if it's still possible, I'd use an array on protocol, host, port to be able to do:

    @URL(host={"hibernate.org", ""www.hibernate.org"})


On 11 avr. 2012, at 10:52, Emmanuel Bernard wrote:

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev