[bv-dev] MethodDescriptors and overloading

Markus Staab maggus.staab at gmail.com
Mon Nov 12 13:03:25 EST 2012


CallableDescriptor.. ?

Markus

Am 12.11.2012 um 18:29 schrieb Emmanuel Bernard <emmanuel at hibernate.org>:

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


More information about the beanvalidation-dev mailing list