[bv-dev] MethodDescriptors and overloading

[Matt Benson]

No arguments here, then.  Good find, Gunnar!

Matt


On Thu, Nov 15, 2012 at 4:24 PM, Gunnar Morling <gunnar at hibernate.org>wrote:

> As life goes, I just learned that there will be a common super interface
> of java.lang.reflect.Method and Constructor in JDK 8, called ... Executable
> :) [1]. In that light ExecutableDescriptor seems like the best option to me.
>
> --Gunnar
>
> [1]
> http://download.java.net/jdk8/docs/api/index.html?java/lang/reflect/Executable.html
>
>
> 2012/11/12 Matt Benson <mbenson at apache.org>
>
>>
>>
>>
>> On Mon, Nov 12, 2012 at 3:11 AM, Gunnar Morling <gunnar at hibernate.org>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
>>>
>>> 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 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
>>
>>
>
> _______________________________________________
> 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/20121115/bca74f81/attachment-0001.html