[bv-dev] MethodDescriptors and overloading

Gunnar Morling gunnar at hibernate.org
Mon Nov 12 04:11:53 EST 2012


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20121112/89bc685a/attachment.html 


More information about the beanvalidation-dev mailing list