On 8 avr. 2011, at 17:16, Kevin Pollet wrote:
> On vendredi 8 avril 2011 at 15:54, Emmanuel Bernard wrote:
>> Make sure you write a client of this API, I suspect Class...
>> parameterTypes might not be what you want.
>>
>> On 8 avr. 2011, at 13:41, Kevin Pollet wrote:
>
> What do you mean ?
On vendredi 8 avril 2011 at 15:54, Emmanuel Bernard wrote:
Make sure you write a client of this API, I suspect Class... parameterTypes
might not be what you want.
>
> On 8 avr. 2011, at 13:41, Kevin Pollet wrote:
What do you mean ?
Have you a tricky/special case in mind ?
--Kevin
___
Make sure you write a client of this API, I suspect Class... parameterTypes
might not be what you want.
On 8 avr. 2011, at 13:41, Kevin Pollet wrote:
> On vendredi 8 avril 2011 at 13:13, Gunnar Morling wrote:
>
>> Hi,
>>
>> I also like https://gist.github.com/903302#file_1_method_configuration
On vendredi 8 avril 2011 at 13:13, Gunnar Morling wrote:
Hi,
>
> I also like https://gist.github.com/903302#file_1_method_configuration.java
> best. As we already decided to accept some breaking changes around
> ConstraintDef, I also think it's better to do other breaking changes
> now instead of
Hi,
I also like https://gist.github.com/903302#file_1_method_configuration.java
best. As we already decided to accept some breaking changes around
ConstraintDef, I also think it's better to do other breaking changes
now instead of later.
Just one remark: we need a way to clearly identify overload
On 8 avr. 2011, at 11:09, Hardy Ferentschik wrote:
> On Fri, 08 Apr 2011 10:47:37 +0200, Emmanuel Bernard
> wrote:
>
>> What does
>> //this version doesn't break the compatibility
>> means on other versions?
>
> I also prefer https://gist.github.com/903302#file_1_method_configuration.java
> T
On Fri, 08 Apr 2011 10:47:37 +0200, Emmanuel Bernard
wrote:
> What does
> //this version doesn't break the compatibility
> means on other versions?
I also prefer
https://gist.github.com/903302#file_1_method_configuration.java
This version means though that people already using the programmat
https://gist.github.com/903302#file_1_method_configuration.java
seems the one that makes most sense by far to me. The other options tend to
make method a super concept that is not symmetric with .property()
What does
//this version doesn't break the compatibility
means on other versions?
Emmanu
Hi guys,
I'm working on HV-431,
http://opensource.atlassian.com/projects/hibernate/browse/HV-431.
The aim of this issue is to extend the programmatic API to allow constraints
definition on methods in a programmatic way. I've discussed with Hardy about
some proposals and I've made a gist to ex
