In the article he makes this comment:
There is now an option to generateI've not yet seen the toString generator, but having written more than enough toString implementations, I've worried that such a code generator may be less than ideal. Similarly, I've seen the equals and hashCode generators at work, and I also tend to not want to use them.
toStringautomatically. This is something I've wanted for a long time. Unfortunately, it is not very good. Core Java gives these simple rules for
The Eclipse formatter follows neither of these eminently sensible rules. Maybe in 3.6.
getClass().getName()to print the class name. Then your
toStringcan be inherited.
- When you redefine
toStringin a subclass, first call
super.toString(), then add the subclass data.
Given that I work for a company that has so much Java code that "If code was ice cream, it would be a lot of ice cream," [Ref Java Posse 240, 9:15] in addition to having very helpful helper methods for hashCode and equals, I'd love more finely-tuned generators for such critical methods.
But I feel a bit constrained by one of the basic rules guiding Eclipse contributions, as defined by the book Eclipse: Principles, Patterns and Plug-ins:
As the Contribution Rule reminds us, “Everything is a contribution.” And with many contributions, the possibilities are endless.OK, so let's say I write my own generators for toString, hashCode and equals. Then there are two toString generators in the IDE, one possibly better than the other. Why should the end user be forced to deal with two confusing UI contributions?
Sure, there's also the recent object of my affections, patch fragments, but the patch fragment is a back-door lover.
I want to remove the default contributions altogether, and replace them with something better suited to my environment. But that violates the Contribution Rule. Am I stuck with something less than ideal until Eclipse 3.6, or worse, forever?
What's the solution here?
PS: Has someone picked up on Cay's concerns and logged a bug?