Problem Statement
Currently, both EqualsVisitor and NoCommentEqualsVisitor are fully generated from metadata via the code generator. While they serve slightly different purposes—NoCommentEqualsVisitor checks strictly for structural/node equality, while EqualsVisitor also validates comment equality—their implementations share roughly 90% of the same boilerplate code.
Because the JavaParser AST treats comments as isolated metadata independent of the specific node type, the comment equality check can be applied uniformly. Generating two entirely independent classes for this creates unnecessary code duplication and increases the maintenance surface of the generator.
Proposed Changes
In alignment with the KISS (Keep It Small and Simple) principle, I propose refactoring this relationship:
- Remove EqualsVisitor from the code generation process.
- Refactor EqualsVisitor to manually extend NoCommentEqualsVisitor.
- Centralize the comment check. By leveraging inheritance, EqualsVisitor only needs to handle the core node equality logic by delegating to super, and then applying the uniform comment validation.
Benefits
Reduces Boilerplate: Eliminates hundreds of lines of duplicated generated code.
Easier Maintenance: Fixes or improvements to the core structural equality logic only need to be updated/generated in one place (NoCommentEqualsVisitor).
Cleaner Architecture: Better reflects the conceptual model that EqualsVisitor is a NoCommentEqualsVisitor with an additional layer of verification.
Problem Statement
Currently, both EqualsVisitor and NoCommentEqualsVisitor are fully generated from metadata via the code generator. While they serve slightly different purposes—NoCommentEqualsVisitor checks strictly for structural/node equality, while EqualsVisitor also validates comment equality—their implementations share roughly 90% of the same boilerplate code.
Because the JavaParser AST treats comments as isolated metadata independent of the specific node type, the comment equality check can be applied uniformly. Generating two entirely independent classes for this creates unnecessary code duplication and increases the maintenance surface of the generator.
Proposed Changes
In alignment with the KISS (Keep It Small and Simple) principle, I propose refactoring this relationship:
Benefits
Reduces Boilerplate: Eliminates hundreds of lines of duplicated generated code.
Easier Maintenance: Fixes or improvements to the core structural equality logic only need to be updated/generated in one place (NoCommentEqualsVisitor).
Cleaner Architecture: Better reflects the conceptual model that EqualsVisitor is a NoCommentEqualsVisitor with an additional layer of verification.