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(a)hibernate.org <mailto: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(a)web.de <mailto: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(a)hibernate.org
<mailto: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(a)hibernate.org <mailto: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(a)web.de <mailto: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(a)lists.jboss.org
<mailto:beanvalidation-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
<mailto:beanvalidation-dev@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