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

Wed May 10 11:06:36 EDT 2017

Ok I yield. 
But you have to admit that making sure a signed int is always 0 or positive is probably the most common though low value usage you will find. And it's low value unless you factor security consideration at which stage it become a very very good idea to litter your code with these. 

@Positive
int age, nbrOfApples, nbrOfFriends, starRatingAverage, votingParticipants;

> On 10 May 2017, at 09:55, Marco Molteni <moltenma at gmail.com> wrote:
> 
> I'd go with default strict to true. It's supported by the mathematical definition of Positive/Negative number.
> 
> Very difficult to know the more common scenario (in a quick informal poll between developers near me everybody was confused).
> 
> I found this implementation of Zalando  for a monetary amount and they use the strict interpretation for @Positive/Negative annotations and they added @PositiveOrZero/@NegativeOrZero to include the 0  : https://github.com/zalando/money-validation#usage 
> 
> The Eclipse Collections (ex-Goldman Sachs collections) defines positive number > 0 (strict case), https://github.com/goldmansachs/gs-collections. I would say that the more common scenario is to exclude the 0.
> 
> Marco
> 
>> On Wed, May 10, 2017 at 3:40 AM, Matt Benson <mbenson at apache.org> wrote:
>> My last response might have made sense if I'd have sent my previous
>> one (to Emmanuel) from the right address:
>> 
>> "Less common" is an opinion. Are there survey data to back it up? By
>> contrast, a literal or "strict" interpretation of past or future is
>> something that cannot be questioned.
>> 
>> ;)
>> 
>> Matt
>> 
>> On Tue, May 9, 2017 at 6:52 PM, Matt Benson <mbenson at apache.org> wrote:
>> > That's why I advocate being literal; then you don't have to guess at
>> > people's intention. Can't they compose a version that defaults strict to
>> > false?
>> >
>> > Matt
>> >
>> > On May 9, 2017 6:22 PM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>> >>
>> >> Is inclusive more common really? My feeling is that one would want to
>> >> exclude 0 more often than not. But I don't have any good idea of how
>> >> to quantify that...
>> >>
>> >> 2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>> >> > Well I object :)
>> >> > You are addressing the less common scenario with this default.
>> >> >
>> >> >> On 9 May 2017, at 11:09, Gunnar Morling <gunnar at hibernate.org> 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 at hibernate.org>:
>> >> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>> >> >>>> Hi,
>> >> >>>>
>> >> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> >> >>>>> 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 at lists.jboss.org
>> >> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >>>> _______________________________________________
>> >> >>>> beanvalidation-dev mailing list
>> >> >>>> beanvalidation-dev at lists.jboss.org
>> >> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >>> _______________________________________________
>> >> >>> beanvalidation-dev mailing list
>> >> >>> beanvalidation-dev at lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >> _______________________________________________
>> >> >> beanvalidation-dev mailing list
>> >> >> beanvalidation-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > beanvalidation-dev mailing list
>> >> > beanvalidation-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170510/5314d007/attachment-0001.html 