Reuse visitor instances in getter methods

[Victor Nazarov]

String getName() {
    return this.accept(new UserVisitor<String>() {
        @Override
        public String of(String name, int age) {
            return name;
        }
    });
}

should probably become

private static final UserVisitor<String> GET_NAME_VISITOR = new UserVisitor<String>() {
     @Override
     public String of(String name, int age) {
         return name;
     }
 };
String getName() {
    return this.accept(GET_NAME_VISITOR);
}

in generated code

[Mark Derricutt]

As part of a code-review with a coworker just now, I asked him to go over the generated code to understand the implications of what we were adding, and we came across the the generated equals and hashCode methods both use accept and create new instances of their respective visitors each time ( two nested visitors in the equals case actually ) so moving these to private static final's as well would be good to do at the time.

Further discussion also led to the idea that for hashCode, instead of using accept simply delegating to acceptor.hashCode() and generating the appropriate hashCode method there might be even better.

The performance hit that one might incur if having a list/set containing a lot of ADT4j instances could be an issue. I think I might write up some microbenchmark tests and compare some values.

[Victor Nazarov]

I've just released 0.13 version. It has been refactored to deliver almost no allocations in generated methods.

[Mark Derricutt]

+1000! Awesome. Will update and check out the new code and report back.

[Mark Derricutt]

Just checked the new generated code - +1000 ontop of that earlier 1000. That's looking much nicer, and from what I can see (without running benchmarks) my code which does A LOT of iteration of A LOT of ADT4j instances seems to be running MUCH MUCH faster.

What the hell - have another +1000 :)

[Victor Nazarov]

What's your opinion about generated code for equals and compareTo. Should we try to improve it? Should we try to get rid of boolean and int boxing? Or should we better leave current version as is?

[Jean-Baptiste G.]

I just noticed there is a little problem with the generated *AcceptorEqualsVisitor classes: they do not implement Serializable even though valueClassIsSerializable is at true.
Maybe a better option could be to make the field transient and initialized it at first use if null?

[Victor Nazarov]

@jbgi Can you test HEAD of master? It should be fixed now.