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@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@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@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@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@hibernate.org>:
>> >>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>> >>>> Hi,
>> >>>>
>> >>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson@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@lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >>>> _______________________________________________
>> >>>> beanvalidation-dev mailing list
>> >>>> beanvalidation-dev@lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >>> _______________________________________________
>> >>> beanvalidation-dev mailing list
>> >>> beanvalidation-dev@lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >> _______________________________________________
>> >> beanvalidation-dev mailing list
>> >> beanvalidation-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> >
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev