If it should be human understandable I'm still for "<return value>" but for programmatic usage it may be even better to have a string identifier as short as possible to avoid extensive string comparison operations. Maybe even something like "<>" or even an empty string.

seb

On 10.02.2013 19:55, Matt Benson wrote:
Come on, Hardy, join me in supporting <result> which avoids whitespace and encompasses the full meaning of "return value".  :)

Matt


On Sun, Feb 10, 2013 at 4:42 AM, Hardy Ferentschik <hardy@hibernate.org> wrote:
Personally I don't like the whitespace in <return value>. I would prefer <return>.
However, if the majority agrees to  <return value> that's fine with me. I like the the use of <>.

--Hardy


On 9 Jan 2013, at 3:05 PM, Sebastian Thomschke <sebastian.thomschke@web.de> wrote:

> +1 for "<return value>" too
>
> seb
>
> On 09.02.2013 12:03, Gunnar Morling wrote:
>> +1 for <return value>.
>>
>> --Gunnar
>>
>>
>>
>> 2013/2/8 Emmanuel Bernard <emmanuel@hibernate.org>
>> I am not a big fan of the retval which reminds me of Gollum skeaping his
>> name ;)
>>
>> - <return value>
>> - <return>
>> - (return value)
>> - (return)
>>
>> I think I like <return value> the best.
>>
>> As Hardy said, the name is not critical as nodes are identified by their
>> elementDescriptor.kind.
>>
>> Emmanuel
>>
>> On Fri 2013-02-08 11:19, Matt Benson wrote:
>> > I am somewhat attracted to Sebastian's suggestion of illegal identifier
>> > characters.  My suggestion would be "<result>".
>> >
>> > Matt
>> >
>> >
>> > On Fri, Feb 8, 2013 at 9:21 AM, Hardy Ferentschik <hardy@hibernate.org>wrote:
>> >
>> > > I don't want to introduce a name for the return value to allow things like
>> > >
>> > > if(node.getName.equals("retval")) {
>> > >         ReturnValueDescriptor descriptor = (ReturnValueDescriptor)
>> > > node.getElementDescriptor();
>> > > }
>> > >
>> > > The actual type of a node is still given by it ElementDescriptor. The name
>> > > cannot be used for that. It is more for convenience
>> > > and "nice" toString implementation. Yes it could be ambiguous, but I don't
>> > > think it matters. Any code relying on the property path
>> > > as string is potentially wrong anyways. A white space seems odd,
>> > > especially in the light of toString.
>> > >
>> > > In that light $retval might be a legal java identifier, but chances are
>> > > slim someone uses it.
>> > >
>> > > --Hardy
>> > >
>> > >
>> > > On 8 Jan 2013, at 4:07 PM, Sebastian Thomschke <sebastian.thomschke@web.de>
>> > > wrote:
>> > >
>> > > > What if there is a property or method called "returnValue"? I think the
>> > > constant string returned should contain a character that is not legal for
>> > > java identifier names. E.g. a white space.
>> > > >
>> > > > seb
>> > > >
>> > > > On 08.02.2013 12:51, Gunnar Morling wrote:
>> > > >> Experts,
>> > > >>
>> > > >> another issue where we need some feedback is BVAL-368, which is about
>> > > the name of path nodes representing return values.
>> > > >>
>> > > >> As per the current draft, Node#getName() returns null in that case.
>> > > Question is, whether we should return something more meaningful, and if so,
>> > > which value.
>> > > >>
>> > > >> The RI used to return "$retval" before we change this to match the
>> > > spec. Another obvious option would be "returnValue". Having a standardized
>> > > node name for return value nodes would also help with better toString()
>> > > implementations for j.v.Path (although that's not standardized).
>> > > >>
>> > > >> Any thoughts?
>> > > >>
>> > > >> Thanks,
>> > > >>
>> > > >> --Gunnar
>> > > >>
>> > > >> [1] https://hibernate.onjira.com/browse/BVAL-368
>> > > >>
>> > > >>
>
> _______________________________________________
> 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