[bv-dev] MethodDescriptors and overloading

[Emmanuel Bernard]

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 at apache.org>
> 
> > 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 at hibernate.org>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 at apache.org>:
> >>
> >>> 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 at apache.org> 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>
> >>>
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>
> >>
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >

> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev