8:40 p.m.
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(a)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(a)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(a)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(a)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(a)hibernate.org>:
> >>>> 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>:
> >>>>> 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
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev