Re: [bv-dev] Name for path nodes representing return values

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 &gt;&lt;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 &gt;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