10:11 a.m.
2012/11/10 Matt Benson <mbenson(a)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(a)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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev