Here you are:
public String toString() {
try {
StringBuffer sb = new StringBuffer(super.toString());
Field[] fields = this.getClass().getDeclaredFields();
for (int i = 0; i < fields.length; i++) {
sb.append("
").append(fields[i].getName()).append("=").append(fields[i].get(this)).appen
d(";");
}
return sb.toString();
} catch (Exception e) {
throw new RuntimeException(e.toString());
}
}
public boolean equals(Object obj) {
if (!super.equals(obj)) return false;
if (!this.getClass().isAssignableFrom(obj.getClass())) return false;
try {
Field[] fields = this.getClass().getDeclaredFields();
for (int i = 0; i < fields.length; i++) {
Field field = fields[i];
if (field.get(this).equals(field.get(obj))) return false;
}
return true;
} catch (Exception e) {
throw new RuntimeException(e.toString());
}
}
public int hashCode() {
try {
int c = super.hashCode();
Field[] fields = this.getClass().getDeclaredFields();
for (int i = 0; i < fields.length; i++) {
c = c*37 + fields[i].get(this).hashCode();
}
return c;
} catch (Exception e) {
throw new RuntimeException(e.toString());
}
}
Insert this code snippet in your object and you get "canonical" behavior.
Note that the equals method is not reflexive if used with polymorphic
classes (Joshua Bloch mentioned that in his book)
Feel free to comment :)
-- dimiter
"Alain Ravet" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> dimiter wrote:
>
> > At least for me these generated methods don't add any value.
>
>
> Ever written this code for 5 15+ field classes, that map objects to DB
> data? Pretty boring, and error prone.
>
>
> > If I want equals I prefer to write it myself and to determine
precisely
> > which variables define the state of my class,
>
>
> So do I; but I start from a complete and functionning skeleton, that I
> tune if necessary.
> Less error prone. Helps me be consistent, across classes.
> The "template" side is an extra advantage for team consistency.
>
>
> > if I write toString - I want
> > to see concise description and not full memory dump (that's what the
> > debugger is for).
>
>
> So do I; but ...
>
>
> > But if you feel more comfortable with standard implementations,
>
>
> I use Joshua Bloch - "Effective Java" - /standard/.
>
>
http://www.amazon.co.uk/exec/obidos/ASIN/0201310058/qid=1023090468/sr=2-1/re
f=sr_2_3_1/026-2098539-4510843
> A good enough standard to start with.
>
>
> > you could
>
> > use the generic versions and rewrite them yourself if the profiling
shows
> > them as bottlenecks (I've seen this very rarely).
>
>
> Having this task automated helps a lot.
> No more "do I really need to spend 5-20 minutes making this object
> canonical, when all I need is a basic toString().
>
>
> Having this task integrated would help even more : modifiying the class
> structure would trigger change/notification. It's not top priority, but
> like many IDEA cool "little" features, they quickly become invaluable.
>
> > so from me it gets -1
>
>
> Does "-1" mean that
> - you would write a plug-in to remove it from the standard menus,
> to save space,
>
> or simply that you think that
> - you would never use it
> ?
>
> Alain
>
> ------------------------------------
>
> >>Martin Bayly wrote:
> >>>I find it tedious to write equals, hashcode and toString methods for
> >>>classes. It would be great if IDEA could do this for me by examing
> >>>the fields of a class and generating/maintaining a default
> >>>implementation of these methods.
>
>
> > Alain Ravet wrote:
> >>+5
> >>This is an old request - and battle - : make objects canonical.
> >>In the meantime, I solved this with a doclet. Not perfect, but good
> > enough.
> >>Integration would be better, though.
>
>
_______________________________________________
Eap-features mailing list
[EMAIL PROTECTED]
http://lists.jetbrains.com/mailman/listinfo/eap-features
