Re: [bv-dev] Questions from BV spec 2.0 public draft

Well I object :) You are addressing the less common scenario with this default. > On 9 May 2017, at 11:09, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > Hi all, > > So my preference is to make strict() default to true (so it's > consistent with the default value for orPresent() of @Past/@Future). > I've filed PR https://github.com/beanvalidation/beanvalidation-api/pull/106. > > If there are no objections by Thursday, I'll merge it then. > > Thanks for any comments, > > --Gunnar > > > 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >>> On Wed 17-04-26 10:40, Gunnar Morling wrote: >>> Hi, >>> >>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: >>>> After reviewing the proposed API, I have the following >>>> questions/suggestions. I apologize if any of these have already been >>>> considered: >>>> >>>> * Should there be a common superinterface for >>>> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define >>>> the same methods? >>> >>> I've been wondering the same, but come to think that it doesn't give you much. >>> >>> You (as a user) are going to work with specific node types (as >>> narrowed down via getKind() + as()), so I would not expect you to deal >>> with that super-type in your code. It'd put the declaration of those >>> methods into one place, which is nice, though I kinda like the >>> simplicity of the current Node hierarchy, with one specific sub-type >>> per kind. >>> >>> What do others think? >> >> I think that was my idea for not adding a hierarchy back in 1.x. >> >>> >>>> >>>> * Should ValidatorContext include a self type, as does Configuration? >>>> This would facilitate the use of custom ValidatorContext subclasses. >>> >>> Ah, there's even an issue for this: >>> https://hibernate.atlassian.net/browse/BVAL-211. >>> >>> It would have been great to make this a self-referential type from the >>> get-go, but at this point I'd rather leave it as is. Essentially it >>> only causes a small effort to providers which need to redeclare all >>> the ValidatorContext methods to return their own specialised sub-type. >>> >>> The reason I'm reluctant to add it is that users - when upgrading >>> existing code to BV 2.0 - will get a raw type warning when assigning >>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost >>> of the few method re-definitions to be done by providers once, which >>> seems acceptable. >>> >>>> >>>> * Should Positive/Negative#strict() default true be provided as >>>> #orZero() default false, for commonality with >>>> [Past|Future]#orPresent() ? >>> >>> Hum, yes, good point. I think I'd prefer that. >>> >>> @Emmanuel, I vaguely remember we discussed this. Did you see a good >>> reason for the current default? >> >> I don't even vaguely remember talking about it. Sounds good. >> Actually I remember now, we discussed whether Positive#orZero should be >> defaulted to true. >> >> I imagine that >=0 is the most common use case for @Positive (despite >> the math definition). >> As for @Negative, I'm on the fence. >> >>> >>> @All, what do you think? >>> >>>> >>>> Matt >>> >>> --Gunnar >>> >>>> _______________________________________________ >>>> beanvalidation-dev mailing list >>>> beanvalidation-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >>> _______________________________________________ >>> beanvalidation-dev mailing list >>> beanvalidation-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev