Re: [bv-dev] MethodDescriptors and overloading

I personally like InvocableDescriptor, ExecutableDescriptor and MethodDescriptor. But MethodDescriptor might not be wise if we need to add constructor or method specific methods down the road. Emmanuel On Mon 2012-11-12 10:11, Gunnar Morling 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 > > 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev