8:54 a.m.
The problem with returning `null` is that it literally creates an
exception clause in your code.
if (eltdescriptor == nukk) {
/something
}
else {
switch(eltdescriptor.getKind()) {
case PARAMETER:
//do something
...
}
So we might want to explore the idea of adding a `UnknownDescriptor` or
`FreeNodeDescriptor` is a specific kind for ad-hoc created via the API.
Should we have the ability to provide the element descriptor when
creating a node? That's a good question. It woud be nice if you could
explore how the code would look like in a "real life" example and see
where getting the elementDescriptor makes the most sense.
Emmanuel
On Fri 2012-11-23 15:21, Gunnar Morling wrote:
> - relaxing NodeBuilderDefinedContext and adding the new contract
on it
I wouldn't really like that as it reduces safety of the API.
> - an explicit new method deprecating addNode
Related to this is BVAL-336 [1]. We've added Node#getDescriptor(), so the
question is what should that return for nodes created by the user via the
node builder API?
We could have a new method
addNode(String name, ElementDescriptor descriptor) or even
addNode(ElementDescriptor descriptor)
Leaves the question where does the user get the descriptor from? One way
could be to provide access to BeanDescriptor via ConstraintValidatorContext.
For nodes added via the deprecated method getDescriptor() we would likely
have to return null.
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-336
2012/11/23 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I guess you always learn something new every day :)
> This is indeed only working if we use interception types.
>
> The question is do we want to do that or lean towards one of the
> alternative methods:
>
> - an explicit new method deprecating addNode
> - relaxing NodeBuilderDefinedContext and adding the new contract on it
>
> Emmanuel
>
> On Fri 2012-11-23 12:57, Gunnar Morling wrote:
> > Hi,
> >
> > > Another approach would be to make NodeBuilderCustomizableContext a sub
> > insterface of NodeBuilderDefinedContext.
> >
> > I think changing the return type of ConstraintViolationBuilder#addNode()
> > to NodeBuilderCustomizableContext is a problem.
> >
> > While that change is source compatible (code using addNode() can be
> > compiled against the new API version without having to be adapted) it is
> > not binary compatible. That is, code compiled against the previous
> version
> > will fail at runtime:
> >
> > java.lang.NoSuchMethodError:
> >
>
javax.validation.ConstraintValidatorContext$ConstraintViolationBuilder.addNode(Ljava/lang/String;)Ljavax/validation/ConstraintValidatorContext$ConstraintViolationBuilder$NodeBuilderDefinedContext;
> >
> > This error occurs, no matter wether the result of addNode() is assigned
> to
> > a variable or not.
> >
> > What we might try to do is to return an intersection type from
> > ConstraintViolationBuilder#addNode() like this:
> >
> > interface ConstraintViolationBuilder {
> >
> > <T extends NodeBuilderDefinedContext &
> NodeBuilderCustomizableContext>
> > T addNode(String name);
> >
> > ConstraintValidatorContext addConstraintViolation();
> > }
> >
> > This is source compatible and AFAICS it's also binary compatible because
> > the erasure of T is its leftmost bound, that is
> NodeBuilderDefinedContext.
> > That way code compiled against the old API can still dispatch the
> addNode()
> > method, while code written against the new version can invoke all methods
> > defined on NodeBuilderDefinedContext and NodeBuilderCustomizableContext.
> >
> > Btw. I stumbled upon [1] which gives a very good overview on the
> > compatibility of all sorts of API changes.
> >
> > --Gunnar
> >
> > [1]
> >
> http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_Interfaces
> >
> >
> > 2012/11/22 Emmanuel Bernard <emmanuel(a)hibernate.org>
> >
> > > Unless anyone has concern, I plan to go for option 3 on
> > > http://beanvalidation.org/proposals/BVAL-221/
> > > _______________________________________________
> > > 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