1:15 p.m.
Hello,
Matthew argues for a new basic constraint named `@Nullable`. The goal is
to make it clear when an element is nullable. Today you can guess it
from the fact that it does not host a `@NotNull` constraint. But it's
ambiguous as someone might have simply forgotten the constraint.
https://hibernate.onjira.com/browse/BVAL-341
I am not in favor of this for a few reasons. I think what Matthew is
after is `@Nullable` with the semantic of JSR 305: the element is always
nullable no matter what - and possibly can be computed by a tool at
compile time. But since Bean Validation is only validated at specific
moments in the life cycle of an object or method and that different
groups can be validated, I don't feel that `@Nullable` would bring all
the promises one would expect.
Thoughts?
Emmanuel
1:27 p.m.
Adding a further constraint to prevent situations where developers forget
to add constraints feels a bit clumsy to me, not to mention verbose. I can
see how this might be useful to one person, but I wouldn't want the mess of
a team applying this inconsistently. I'd prefer convention over
configuration in this instance, personally.
On Wednesday, 2 January 2013, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
Hello,
Matthew argues for a new basic constraint named `@Nullable`. The goal is
to make it clear when an element is nullable. Today you can guess it
from the fact that it does not host a `@NotNull` constraint. But it's
ambiguous as someone might have simply forgotten the constraint.
https://hibernate.onjira.com/browse/BVAL-341
I am not in favor of this for a few reasons. I think what Matthew is
after is `@Nullable` with the semantic of JSR 305: the element is always
nullable no matter what - and possibly can be computed by a tool at
compile time. But since Bean Validation is only validated at specific
moments in the life cycle of an object or method and that different
groups can be validated, I don't feel that `@Nullable` would bring all
the promises one would expect.
Thoughts?
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:35 p.m.
-1 for @Nullable. It is not a constraint in the Bean Validation sense. It provided
different type of metadata.
--Hardy
On 2 Jan 2013, at 1:15 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Hello,
Matthew argues for a new basic constraint named `@Nullable`. The goal is
to make it clear when an element is nullable. Today you can guess it
from the fact that it does not host a `@NotNull` constraint. But it's
ambiguous as someone might have simply forgotten the constraint.
https://hibernate.onjira.com/browse/BVAL-341
I am not in favor of this for a few reasons. I think what Matthew is
after is `@Nullable` with the semantic of JSR 305: the element is always
nullable no matter what - and possibly can be computed by a tool at
compile time. But since Bean Validation is only validated at specific
moments in the life cycle of an object or method and that different
groups can be validated, I don't feel that `@Nullable` would bring all
the promises one would expect.
Thoughts?
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6:27 p.m.
Hi,
I am -1 for adding @Nullable only for the reason described in
https://hibernate.onjira.com/browse/BVAL-341. It is redundant.
In OVal we are using an @Nullable annotation to weaken constraints in
the context of programming by contract.
In the following example on class level is defined that all parameters
of all methods require non-null values, this is then weakened for some
of the parameters using @Nullable. This can be seen as a convenient
approach used e.g. for classes where the majority of parameters must not
be null and only a few should be nullable.
@net.sf.oval.guard.Guarded(assertParametersNotNull = true)
public static class TestEntity
{
protected TestEntity1(final String param1, @Nullable final
String param2)
{ }
public void setParam1(final String param1)
{ }
public void setParam2(@Nullable final String param2)
{ }
}
Regards,
Seb
On 02.01.2013 13:15, Emmanuel Bernard wrote:
Hello,
Matthew argues for a new basic constraint named `@Nullable`. The goal is
to make it clear when an element is nullable. Today you can guess it
from the fact that it does not host a `@NotNull` constraint. But it's
ambiguous as someone might have simply forgotten the constraint.
https://hibernate.onjira.com/browse/BVAL-341
I am not in favor of this for a few reasons. I think what Matthew is
after is `@Nullable` with the semantic of JSR 305: the element is always
nullable no matter what - and possibly can be computed by a tool at
compile time. But since Bean Validation is only validated at specific
moments in the life cycle of an object or method and that different
groups can be validated, I don't feel that `@Nullable` would bring all
the promises one would expect.
Thoughts?
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4133
days inactive
4138
days old
beanvalidation-dev@lists.jboss.org
4 comments
5 participants
participants (5)
-
Cemo -
Emmanuel Bernard -
Hardy Ferentschik -
Rich Midwinter -
Sebastian Thomschke