Hello James,
in my current code the allFields property of the @EqualsClass
annotation controls whether all fields are automatically used, like
this:
// the simplest case
@EqualsClass(allFields=true)
private static final class OneField {
public int value;
}
...and additionally @EqualsProperty annotation can be used to choose
fields like this:
@EqualsClass
private static final class ProtectedField {
@EqualsProperty
protected int value;
private int value2; // this is not used in equals, because it
is not annotated
}
I have just started to write the code and even the names of the
annotations could change, as I would try to align the usage of
annotations
with similar cases (e.g. EJB3).
I also have been thinking about annotating whole packages...
Annotating the getters could be also useful.
Regards
--Tim
On Tue, Jan 6, 2009 at 7:21 PM, James Carman <ja...@carmanconsulting.com> wrote:
> I wouldn't think you'd want the AutomaticEquals stuff to be at the
> top-level, necessarily. Can you annotate property getters or perhaps
> the fields themselves?
>
> On Tue, Jan 6, 2009 at 10:59 AM, Tim Lebedkov <tim.lebed...@web.de> wrote:
>> Hello Viraj,
>>
>> the first case (@XYZ) is how I thought about it (see also the test
>> code in the attachment). This way .equals() could be implemented
>> automatically.
>> Of course you have to override the equals() method like this, if you
>> would like it to behave "as designed":
>>
>> // maybe some sort of postprocessing for class files could make this
>> unnecessary
>> @Override
>> public boolean equals(Object b) {
>> return Automatic.equals(this, b);
>> }
>>
>> the second case also looks interesting and may be useful.
>>
>> Regards
>> --Tim
>>
>> On Tue, Jan 6, 2009 at 3:57 PM, Viraj Turakhia <virajturak...@gmail.com>
>> wrote:
>>> HI Tim,
>>> This project interests me. Would like to know more about it.
>>> Could you please explain this better?
>>>
>>> I am confused, what will I do if I want my class's objects to be
>>> compared using XYZ.equals();?
>>> Will I write it as:
>>>
>>> @XYZ
>>> public class MyClass{
>>> ...
>>> ...
>>> ...
>>> }
>>>
>>> or
>>>
>>> @Annot(equals="XYZ" compareTo="MyComparator")
>>> public class MyClass{
>>> ...
>>> ...
>>> ...
>>> }
>>>
>>> LMK.
>>>
>>> -v
>>>
>>> On Tue, Jan 6, 2009 at 7:11 PM, Tim Lebedkov <tim.lebed...@web.de> wrote:
>>>> Hello dev@commons.apache.org reader,
>>>>
>>>> I would like to start a new project (in the sandbox?) for annotation
>>>> based implementation of methods like equals.
>>>> The idea is to annotate a class like this:
>>>>
>>>> @AutomaticEquals
>>>> class Test {
>>>> private int a;
>>>> }
>>>>
>>>> and compare 2 instances of this class using
>>>> AutomaticEquals.equals(test1, test2).
>>>> Which would work just like
>>>> org.apache.commons.lang.builder.EqualsBuilder.reflectionEquals(this,
>>>> obj);
>>>> Additional candidates for annotation based implementations could be
>>>> toString() and compare() and clone().
>>>>
>>>> So here are my questions:
>>>> - is it OK to start a project like this here or should I start one for
>>>> example on code.google.com and move the code later to apache.org?
>>>> - if yes, what would be my next steps?
>>>>
>>>> Regards
>>>> --Tim
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> The first right of human is the right of EGO.
>>> --
>>> http://digmethrough.gebogebo.com
>>> http://www.xperienceexperience.blogspot.com
>>> http://thisiswherewelive.blogspot.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
