Re: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

> On 20 Mar 2018, at 13:24, Guillaume Smet wrote: > > Maybe we could have some gain by avoiding the parameter name generation in > most cases but I'm not sure it's worth making the code less readable. Readability is the root of all evil. I read that somewhere on the

Re: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

This is a spec-level API, defined in ValidatorContext: https://github.com/beanvalidation/beanvalidation-api/blob/master/src/main/java/javax/validation/ValidatorContext.java#L77 So unless we change the rules (there might be some leeway now when formalizing compat rules for Jakarta EE), we cannot

Re: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

Let's hypotethically assume that some scenario needs this. I'm thinking of an application which as different compilation units, so some module might have been compiled with different conventions and need different name resolvers. Would you enforce such a use case to use different, independently

Re: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

Can't you a priori apply your optimization and have a if ( perInstance != perFactory ) backdoor? Meaning I don't really get why you cannot apply your optimization by default and fall back to a slow codepath when the value is overridden. Emmanuel On Mon 18-03-19 17:47, Guillaume Smet wrote: >Hi,

[hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

Hi, So I know we like to have API compatibility discussions these days, so let's start a new one. FWIW, this discussions doesn't come out of the blue, it's based on discussions we had for one of Marko's PRs. In HV, you can set the parameter name provider at the VF level and you can also