[bv-dev] MethodDescriptors and overloading

[Gunnar Morling]

Hi all,

I've created a pull request for BVAL-331 [1].

Note that I've also pulled up getName(), which we originally only had on
MethodDescriptor. I think it makes actually sense for constructors, too. So
we're consistent with Node#getName() in property paths where we also return
the name if a node represents a constructor.

The other thing noteworthy is that I've overridden
ElementDescriptor#getConstraintDescriptors() and findConstraints() to
clarify their behavior for executables. I think it makes sense to restrict
these methods to cross-parameter constraints, as normal parameter
constraints can be found via ParameterDescriptor and return value
constraints via ReturnValueDescriptor.

Please comment if you think any of that makes no sense :)

--Gunnar

[1] https://github.com/beanvalidation/beanvalidation-api/pull/22


2012/11/19 Emmanuel Bernard <emmanuel at hibernate.org>
>
> You underestimate my stubbornness. I am sure we can prove the JDK guys
that they are wrong if we want to ;)
>
>
> On 16 nov. 2012, at 00:10, Matt Benson <mbenson at apache.org> wrote:
>
> 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
>>
>
> _______________________________________________
> 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/20121121/34e40c08/attachment.html