Repository navigation
Introduce BuilderFieldDto as builder working field, map to FieldDto for generation #372
Description
Prep for #349 (simple-codegen moves)
FieldDto currently carries fieldSetterMethodsList (List<BuilderMethodDto> + getMethods/addMethod/removeMethods) — builder-domain working state living on what should be the generic render model. It is the last reference keeping FieldDto (and with it GenerationTargetClassDto) from moving to simple-codegen.
Introduce a separate, standalone BuilderFieldDto in processor.model.core as the working type during builder definition: it carries the field state plus the collected builder methods. BuilderToGenerationTypeMapper maps BuilderFieldDto -> FieldDto when assembling GenerationTargetClassDto — the same pass that already converts BuilderMethodDto -> MethodDto. FieldDto loses the methods list entirely and becomes a pure render type.
Result: FieldDto holds only generic render state and can move to simple-codegen mechanically in #349; builder-domain types stay processor-side per the dependency direction builders -> codegen.
Activity
igel-devin-ai commentedon Oct 23, 2026
Implementation note: done as a plain rename instead of a split. During review it turned out
FieldDtois used only on the builder-definition side — nothing on the generation side consumes it (the render model carriesClassFieldDto), and nothing moving tosimple-codegenin #349 references it. So no genericFieldDtoneeds to exist:FieldDtois renamed toBuilderFieldDto(history preserved viagit mv), keeping the field state andfieldSetterMethodsListtogether in one honestly-named builder-domain type. In #349 it simply stays processor-side.