Re: [bv-dev] MethodDescriptors and overloading

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