P4
There are several ways in which jextract source code generation-related code could be improved.
We currently use ClassSourceBuilder both for top level classes and nested classes. That means for instance that we need to check whether to generate package declarations and import statements, and for nested classes we also emit code into a separate intermediate buffer that is copied into the enclosing buffer when we end the nested class. We can improve the situation by splitting part of the logic in ClassSourceBuilder into a separate SourceFileBuilder, which handles package decl/imports, and holds the underling StringBuilder which allows a nested class to share the buffer with its enclosing class.
Jextract source code generation related code currently relies on method overriding to allow subclasses to inject behavior into the generation code in a super class. This, however, makes it hard to follow what method implementation is actually being called when reading code. And, any method call may become suspicious because it might do something non-obvious. For example, `emitConstructor` is overridden to do nothing in several sub-classes. But, this is not obvious when seeing the emitConstructor() call in ClassSourceBuilder::begin.
Furthermore, we use method overriding for instance to specify the class modifiers for a ClassSourceBuilder subclass, which means that control flow will flow through several class levels when generating code. This, and other cases, could be replaced by a simple (String) value passed to ClassSourceBuilder. Using the direct field value in the generation code makes it clear that there is nothing really special going on (as the method call might imply).
We currently use ClassSourceBuilder both for top level classes and nested classes. That means for instance that we need to check whether to generate package declarations and import statements, and for nested classes we also emit code into a separate intermediate buffer that is copied into the enclosing buffer when we end the nested class. We can improve the situation by splitting part of the logic in ClassSourceBuilder into a separate SourceFileBuilder, which handles package decl/imports, and holds the underling StringBuilder which allows a nested class to share the buffer with its enclosing class.
Jextract source code generation related code currently relies on method overriding to allow subclasses to inject behavior into the generation code in a super class. This, however, makes it hard to follow what method implementation is actually being called when reading code. And, any method call may become suspicious because it might do something non-obvious. For example, `emitConstructor` is overridden to do nothing in several sub-classes. But, this is not obvious when seeing the emitConstructor() call in ClassSourceBuilder::begin.
Furthermore, we use method overriding for instance to specify the class modifiers for a ClassSourceBuilder subclass, which means that control flow will flow through several class levels when generating code. This, and other cases, could be replaced by a simple (String) value passed to ClassSourceBuilder. Using the direct field value in the generation code makes it clear that there is nothing really special going on (as the method call might imply).
