Re: [bv-dev] MethodDescriptors and overloading

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