<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I agree with Gunnar. I'm for option #1
as well.<br>
<br>
seb<br>
<br>
On 09.02.2013 12:12, Gunnar Morling wrote:<br>
</div>
<blockquote
cite="mid:CADGJaX8N9F68cbOQkB2e==_yi5jLsUWQV1dw=Aky6zgOQ51AYg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style="">My personal preference would be #1 as well.</div>
<div style=""><br>
</div>
<div style="">The docs don't say that non-existent nodes are
allowed, so IMO it's ok to clarify now that it is not allowed.
If code relied on adding non-existent nodes, it relied on
behavior not guaranteed explicitly by the spec.</div>
<div style=""><br>
</div>
<div style="">--Gunnar</div>
<div style=""><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/2/8 Emmanuel Bernard <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I had the
same reserve as you but then reading the JavaDoc made me<br>
realize that the doc mentions properties so it is
technically not as<br>
vague as I initially thought.<br>
<span class="HOEnZb"><font color="#888888"><br>
Emmanuel<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
On Fri 2013-02-08 11:48, Matt Benson wrote:<br>
> Personally my reason for eschewing option #1 is the
possibility of breaking<br>
> existing code.<br>
><br>
> Matt<br>
><br>
><br>
> On Fri, Feb 8, 2013 at 11:22 AM, Emmanuel Bernard
<<a moz-do-not-send="true"
href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>wrote:<br>
><br>
> > At this time of day I do tend to like option
#1 (ie making virtual nodes<br>
> > illegal). Otherwise my preferred option is #4<br>
> > (VirtualElementDescriptor).<br>
> ><br>
> > Out of curiosity for people not preferring
option #1. What use case do<br>
> > you see in having virtual nodes?<br>
> ><br>
> > Emmanuel<br>
> ><br>
> > On Fri 2013-02-08 11:08, Matt Benson wrote:<br>
> > > Hmm, a third option for the elementClass
of such a descriptor might be<br>
> > > Void.class.<br>
> > ><br>
> > > I prefer option #3, followed by #4.<br>
> > ><br>
> > > Matt<br>
> > ><br>
> > ><br>
> > > On Fri, Feb 8, 2013 at 5:17 AM, Gunnar
Morling <<a moz-do-not-send="true"
href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>><br>
> > wrote:<br>
> > ><br>
> > > > Hi experts,<br>
> > > ><br>
> > > > One of the remaining issues on our
way to 1.1 is BVAL-336 [1], which is<br>
> > > > about what to return from
Node#getElementDescriptor() for nodes added<br>
> > by<br>
> > > > the user via the
ConstraintViolationBuilder API.<br>
> > > ><br>
> > > > Note that as per the spec only sub
paths can be created by the user,<br>
> > i.e.<br>
> > > > user added nodes always represent
properties but e.g. no methods or<br>
> > > > parameters. Based on that, it seems
right to return the correct<br>
> > > > PropertyDescriptor in case a user
adds a node for an existing property.<br>
> > > ><br>
> > > > Things get tricky though when nodes
are added for non-existent<br>
> > properties.<br>
> > > > Emmanuel, Hardy and I identified the
following options to address this<br>
> > > > situation:<br>
> > > ><br>
> > > > #1 Disallow adding non-existent
nodes<br>
> > > ><br>
> > > > In case a user adds a node but no
property with that names exist, an<br>
> > > > exception is thrown. The problem is
elegantly avoided that way, but we<br>
> > > > might break some 1.0 user code
(currently the spec is not really clear<br>
> > > > whether added nodes must exist or
not).<br>
> > > ><br>
> > > > #2 return null from
getElementDescriptor()<br>
> > > ><br>
> > > > When invoking getElementDescriptor()
on a Node representing a<br>
> > non-existent<br>
> > > > property, null could be returned.
This seems consistent (there is no<br>
> > > > element), but causes additional null
checking when traversing a path.<br>
> > > ><br>
> > > > #3 return a PropertyDescriptor from
getElementDescriptor()<br>
> > > ><br>
> > > > Since all user-added nodes represent
properties, a PropertyDescriptor<br>
> > > > could be returned. hasConstraints()
would return false,<br>
> > > > getConstraintDescriptors() the empty
set etc. This would allow to<br>
> > handle<br>
> > > > all nodes and their descriptors
uniformly when traversing a path.<br>
> > Question<br>
> > > > is what to return from
PropertyDescriptor#getElementClass(). Options<br>
> > are to<br>
> > > > return null (signaling that the
property is non-existent) or<br>
> > Object.class.<br>
> > > ><br>
> > > > #4 return a VirtualDescriptor from
getElementDescriptor()<br>
> > > ><br>
> > > > We could create a new Kind, VIRTUAL,
and an accompanying type<br>
> > > > VirtualDescriptor and return an
instance of this. Behavior of the<br>
> > methods<br>
> > > > on the descriptor would be basically
the same as in #3; getKind()<br>
> > returning<br>
> > > > Kind.VIRTUAL would allow for a very
explicit checking whether the node<br>
> > > > exists or not.<br>
> > > ><br>
> > > > Any feedback on the options (ideally
with arguments pro/con) or other<br>
> > > > alternatives are highly welcome. As
life goes, Emmanuel's, Hardy's and<br>
> > my<br>
> > > > preferences are equally distributed
between these options :)<br>
> > > ><br>
> > > > Thanks,<br>
> > > ><br>
> > > > --Gunnar<br>
> > > ><br>
> > > > [1] <a moz-do-not-send="true"
href="https://hibernate.onjira.com/browse/BVAL-336"
target="_blank">https://hibernate.onjira.com/browse/BVAL-336</a><br>
> > > ><br>
> > > ><br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>