When calling BeanDescriptor#getConstraintsForMethod(...) a caller already knows the full signature of the method about which he is inquiring. With BeanDescriptor#getConstrainedMethods() this is not the case. Once the caller has gotten this information, the only useful things he knows are either (A) that no methods are constrained, or (B) one or more methods are constrained, with a particular set of names. He still has to call #getConstraintsForMethod(...) for every method whose name matches one returned by the gCM() call (let's not discuss how useful it may be to know the highest constrained parameter index). This could be cleared up very simply by adding #getParameterTypes() to MethodDescriptor, and I urge that we do so. Matt

Hi Matt, On MethodDescriptor and ConstructorDescriptor there is a method List<ParameterDescriptor> getParameterDescriptors(). The individual parameter types can be determined via ParameterDescriptor#getElementClass(). Is that what you are after? Btw. it likely makes sense to have a common super interface for MethodDescriptor and ConstructorDescriptor. There's BVAL-331 for this [1]. Suggestions for a good name are welcome, so far ExecutableDescriptor is the best we got. --Gunnar [1] https://hibernate.onjira.com/browse/BVAL-331 Am 09.11.2012 23:29 schrieb "Matt Benson" <mbenson(a)apache.org&gt;: > Same must apply for constructors of course. > > The alternative, IMO, is that #getConstrainedMethods() and > #getConstrainedConstructors() are replaced by boolean > #hasConstrainedMethods() and #hasConstrainedConstructors(), respectively, > as that is all the current methods are really good for. > > Matt > > > On Fri, Nov 9, 2012 at 4:20 PM, Matt Benson <mbenson(a)apache.org&gt; wrote: > >> When calling BeanDescriptor#getConstraintsForMethod(...) a caller >> already knows the full signature of the method about which he is >> inquiring. With BeanDescriptor#getConstrainedMethods() this is not the >> case. Once the caller has gotten this information, the only useful things >> he knows are either (A) that no methods are constrained, or (B) one or >> more methods are constrained, with a particular set of names. He still has >> to call #getConstraintsForMethod(...) for every method whose name matches >> one returned by the gCM() call (let's not discuss how useful it may be to >> know the highest constrained parameter index). This could be cleared up >> very simply by adding #getParameterTypes() to MethodDescriptor, and I urge >> that we do so. >> >> Matt >> > > > _______________________________________________ > 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

2012/11/10 Matt Benson <mbenson(a)apache.org&gt; > You mean that method that was already there in 1.0? :P Yes, that's what > I was looking for. Thanks! > :) > > As for the naming question, I was recently working with Javassist, which > describes the abstraction of "method or constructor" as "behavior," which I > like. What about that? > Personally, I find "behavior" not really appealing, but it's a good idea to look what other libraries use. Based on a short search some more proposals: BehaviorDescriptor ExecutableDescriptor CodeDescriptor InvocableDescriptor InvocableObjectDescriptor MethodOrConstructorDescriptor Add "MemberDescriptor" from java.lang.reflect.Member, implemented by

describing methods *and* constructors. The only method which MethodDescriptor provides in addition to ConstructorDescriptor today is getName(). When representing constructors we could return the (binary) class name, resembling java.lang.reflect.Constructor#getName(). Since the descriptors are already retrieved by separate method calls, this

--Gunnar > > On Fri, Nov 9, 2012 at 6:08 PM, Gunnar Morling <gunnar(a)hibernate.org&gt;wrote: > >> Hi Matt, >> >> On MethodDescriptor and ConstructorDescriptor there is a method >> List<ParameterDescriptor> getParameterDescriptors(). The individual >> parameter types can be determined via >> ParameterDescriptor#getElementClass(). Is that what you are after? >> >> Btw. it likely makes sense to have a common super interface for >> MethodDescriptor and ConstructorDescriptor. There's BVAL-331 for this [1]. >> Suggestions for a good name are welcome, so far ExecutableDescriptor is the >> best we got. >> >> --Gunnar >> >> [1] https://hibernate.onjira.com/browse/BVAL-331 >> Am 09.11.2012 23:29 schrieb "Matt Benson" <mbenson(a)apache.org&gt;: >> >>> Same must apply for constructors of course. >>> >>> The alternative, IMO, is that #getConstrainedMethods() and >>> #getConstrainedConstructors() are replaced by boolean >>> #hasConstrainedMethods() and #hasConstrainedConstructors(), respectively, >>> as that is all the current methods are really good for. >>> >>> Matt >>> >>> >>> On Fri, Nov 9, 2012 at 4:20 PM, Matt Benson <mbenson(a)apache.org&gt; wrote: >>> >>>> When calling BeanDescriptor#getConstraintsForMethod(...) a caller >>>> already knows the full signature of the method about which he is >>>> inquiring. With BeanDescriptor#getConstrainedMethods() this is not the >>>> case. Once the caller has gotten this information, the only useful things >>>> he knows are either (A) that no methods are constrained, or (B) one or >>>> more methods are constrained, with a particular set of names. He still has >>>> to call #getConstraintsForMethod(...) for every method whose name matches >>>> one returned by the gCM() call (let's not discuss how useful it may be to >>>> know the highest constrained parameter index). This could be cleared up >>>> very simply by adding #getParameterTypes() to MethodDescriptor, and I urge >>>> that we do so. >>>> >>>> Matt >>>> >>> >>> >>> _______________________________________________ >>> 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

As life goes, I just learned that there will be a common super interface of java.lang.reflect.Method and Constructor in JDK 8, called ... Executable :) [1]. In that light ExecutableDescriptor seems like the best option to me. --Gunnar [1] http://download.java.net/jdk8/docs/api/index.html?java/lang/reflect/Execu... 2012/11/12 Matt Benson <mbenson(a)apache.org&gt; > > > > On Mon, Nov 12, 2012 at 3:11 AM, Gunnar Morling <gunnar(a)hibernate.org&gt;wrote: > >> >> 2012/11/10 Matt Benson <mbenson(a)apache.org&gt; >> >>> You mean that method that was already there in 1.0? :P Yes, that's >>> what I was looking for. Thanks! >>> >> >> :) >> >> >>> >>> As for the naming question, I was recently working with Javassist, >>> which describes the abstraction of "method or constructor" as "behavior," >>> which I like. What about that? >>> >> >> Personally, I find "behavior" not really appealing, but it's a good idea >> to look what other libraries use. Based on a short search some more >> proposals: >> >> BehaviorDescriptor >> ExecutableDescriptor >> CodeDescriptor >> InvocableDescriptor >> InvocableObjectDescriptor >> MethodOrConstructorDescriptor >> >> Add "MemberDescriptor" from java.lang.reflect.Member, implemented by > Method/Constructor (as well as Field :/ ). > > Alternatively we may also have only one type (MethodDescriptor) for >> describing methods *and* constructors. The only method which >> MethodDescriptor provides in addition to ConstructorDescriptor today is >> getName(). When representing constructors we could return the (binary) >> class name, resembling java.lang.reflect.Constructor#getName(). >> >> Since the descriptors are already retrieved by separate method calls, > this seems reasonable enough to me. > Matt > > >> --Gunnar >> >> >>> >>> On Fri, Nov 9, 2012 at 6:08 PM, Gunnar Morling <gunnar(a)hibernate.org&gt;wrote: >>> >>>> Hi Matt, >>>> >>>> On MethodDescriptor and ConstructorDescriptor there is a method >>>> List<ParameterDescriptor> getParameterDescriptors(). The individual >>>> parameter types can be determined via >>>> ParameterDescriptor#getElementClass(). Is that what you are after? >>>> >>>> Btw. it likely makes sense to have a common super interface for >>>> MethodDescriptor and ConstructorDescriptor. There's BVAL-331 for this [1]. >>>> Suggestions for a good name are welcome, so far ExecutableDescriptor is the >>>> best we got. >>>> >>>> --Gunnar >>>> >>>> [1] https://hibernate.onjira.com/browse/BVAL-331 >>>> Am 09.11.2012 23:29 schrieb "Matt Benson" <mbenson(a)apache.org&gt;: >>>> >>>>> Same must apply for constructors of course. >>>>> >>>>> The alternative, IMO, is that #getConstrainedMethods() and >>>>> #getConstrainedConstructors() are replaced by boolean >>>>> #hasConstrainedMethods() and #hasConstrainedConstructors(), respectively, >>>>> as that is all the current methods are really good for. >>>>> >>>>> Matt >>>>> >>>>> >>>>> On Fri, Nov 9, 2012 at 4:20 PM, Matt Benson <mbenson(a)apache.org&gt;wrote: >>>>> >>>>>> When calling BeanDescriptor#getConstraintsForMethod(...) a caller >>>>>> already knows the full signature of the method about which he is >>>>>> inquiring. With BeanDescriptor#getConstrainedMethods() this is not the >>>>>> case. Once the caller has gotten this information, the only useful things >>>>>> he knows are either (A) that no methods are constrained, or (B) one or >>>>>> more methods are constrained, with a particular set of names. He still has >>>>>> to call #getConstraintsForMethod(...) for every method whose name matches >>>>>> one returned by the gCM() call (let's not discuss how useful it may be to >>>>>> know the highest constrained parameter index). This could be cleared up >>>>>> very simply by adding #getParameterTypes() to MethodDescriptor, and I urge >>>>>> that we do so. >>>>>> >>>>>> Matt >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> > > _______________________________________________ > 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

No arguments here, then. Good find, Gunnar! Matt On Thu, Nov 15, 2012 at 4:24 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > As life goes, I just learned that there will be a common super interface of java.lang.reflect.Method and Constructor in JDK 8, called ... Executable :) [1]. In that light ExecutableDescriptor seems like the best option to me. > > --Gunnar > > [1] http://download.java.net/jdk8/docs/api/index.html?java/lang/reflect/Execu... > > > 2012/11/12 Matt Benson <mbenson(a)apache.org&gt; >> >> >> >> On Mon, Nov 12, 2012 at 3:11 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >>> >>> 2012/11/10 Matt Benson <mbenson(a)apache.org&gt; >>>> You mean that method that was already there in 1.0? :P Yes, that's what I was looking for. Thanks! >>> >>> :) >>> >>>> >>>> As for the naming question, I was recently working with Javassist, which describes the abstraction of "method or constructor" as "behavior," which I like. What about that? >>> >>> Personally, I find "behavior" not really appealing, but it's a good idea to look what other libraries use. Based on a short search some more proposals: >>> >>> BehaviorDescriptor >>> ExecutableDescriptor >>> CodeDescriptor >>> InvocableDescriptor >>> InvocableObjectDescriptor >>> MethodOrConstructorDescriptor >> >> Add "MemberDescriptor" from java.lang.reflect.Member, implemented by Method/Constructor (as well as Field :/ ). >> >>> Alternatively we may also have only one type (MethodDescriptor) for describing methods *and* constructors. The only method which MethodDescriptor provides in addition to ConstructorDescriptor today is getName(). When representing constructors we could return the (binary) class name, resembling java.lang.reflect.Constructor#getName(). >> >> Since the descriptors are already retrieved by separate method calls, this seems reasonable enough to me. >> >> Matt >> >>> --Gunnar >>> >>>> >>>> >>>> >>>> On Fri, Nov 9, 2012 at 6:08 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >>>>> Hi Matt, >>>>> >>>>> On MethodDescriptor and ConstructorDescriptor there is a method List<ParameterDescriptor> getParameterDescriptors(). The individual parameter types can be determined via ParameterDescriptor#getElementClass(). Is that what you are after? >>>>> >>>>> Btw. it likely makes sense to have a common super interface for MethodDescriptor and ConstructorDescriptor. There's BVAL-331 for this [1]. Suggestions for a good name are welcome, so far ExecutableDescriptor is the best we got. >>>>> >>>>> --Gunnar >>>>> >>>>> [1] https://hibernate.onjira.com/browse/BVAL-331 >>>>> >>>>> Am 09.11.2012 23:29 schrieb "Matt Benson" <mbenson(a)apache.org&gt;: >>>>>> Same must apply for constructors of course. >>>>>> >>>>>> The alternative, IMO, is that #getConstrainedMethods() and #getConstrainedConstructors() are replaced by boolean #hasConstrainedMethods() and #hasConstrainedConstructors(), respectively, as that is all the current methods are really good for. >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> On Fri, Nov 9, 2012 at 4:20 PM, Matt Benson <mbenson(a)apache.org&gt; wrote: >>>>>>> When calling BeanDescriptor#getConstraintsForMethod(...) a caller already knows the full signature of the method about which he is inquiring. With BeanDescriptor#getConstrainedMethods() this is not the case. Once the caller has gotten this information, the only useful things he knows are either (A) that no methods are constrained, or (B) one or more methods are constrained, with a particular set of names. He still has to call #getConstraintsForMethod(...) for every method whose name matches one returned by the gCM() call (let's not discuss how useful it may be to know the highest constrained parameter index). This could be cleared up very simply by adding #getParameterTypes() to MethodDescriptor, and I urge that we do so. >>>>>>> >>>>>>> Matt >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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

2012/11/10 Matt Benson <mbenson(a)apache.org&gt; > You mean that method that was already there in 1.0? :P Yes, that's what > I was looking for. Thanks! > :) > > As for the naming question, I was recently working with Javassist, which > describes the abstraction of "method or constructor" as "behavior," which I > like. What about that? > Personally, I find "behavior" not really appealing, but it's a good idea to look what other libraries use. Based on a short search some more proposals: BehaviorDescriptor ExecutableDescriptor CodeDescriptor InvocableDescriptor InvocableObjectDescriptor MethodOrConstructorDescriptor Alternatively we may also have only one type (MethodDescriptor) for describing methods *and* constructors. The only method which MethodDescriptor provides in addition to ConstructorDescriptor today is getName(). When representing constructors we could return the (binary) class name, resembling java.lang.reflect.Constructor#getName(). --Gunnar > > On Fri, Nov 9, 2012 at 6:08 PM, Gunnar Morling <gunnar(a)hibernate.org&gt;wrote: > >> Hi Matt, >> >> On MethodDescriptor and ConstructorDescriptor there is a method >> List<ParameterDescriptor> getParameterDescriptors(). The individual >> parameter types can be determined via >> ParameterDescriptor#getElementClass(). Is that what you are after? >> >> Btw. it likely makes sense to have a common super interface for >> MethodDescriptor and ConstructorDescriptor. There's BVAL-331 for this [1]. >> Suggestions for a good name are welcome, so far ExecutableDescriptor is the >> best we got. >> >> --Gunnar >> >> [1] https://hibernate.onjira.com/browse/BVAL-331 >> Am 09.11.2012 23:29 schrieb "Matt Benson" <mbenson(a)apache.org&gt;: >> >>> Same must apply for constructors of course. >>> >>> The alternative, IMO, is that #getConstrainedMethods() and >>> #getConstrainedConstructors() are replaced by boolean >>> #hasConstrainedMethods() and #hasConstrainedConstructors(), respectively, >>> as that is all the current methods are really good for. >>> >>> Matt >>> >>> >>> On Fri, Nov 9, 2012 at 4:20 PM, Matt Benson <mbenson(a)apache.org&gt; wrote: >>> >>>> When calling BeanDescriptor#getConstraintsForMethod(...) a caller >>>> already knows the full signature of the method about which he is >>>> inquiring. With BeanDescriptor#getConstrainedMethods() this is not the >>>> case. Once the caller has gotten this information, the only useful things >>>> he knows are either (A) that no methods are constrained, or (B) one or >>>> more methods are constrained, with a particular set of names. He still has >>>> to call #getConstraintsForMethod(...) for every method whose name matches >>>> one returned by the gCM() call (let's not discuss how useful it may be to >>>> know the highest constrained parameter index). This could be cleared up >>>> very simply by adding #getParameterTypes() to MethodDescriptor, and I urge >>>> that we do so. >>>> >>>> Matt >>>> >>> >>> >>> _______________________________________________ >>> 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

CallableDescriptor.. ?