You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently a couple node types (Macro, ParsedNode) implement their own patch method which accepts a patch (either ParsedNodePatch or ParsedMacroPatch) and are responsible for applying the contents of the patch to the node attributes. The PatchParsers then call these node patch methods once after constructing a patch.
This splits the overall patching responsibilities into creating a patch and applying it across the PatchParsers and Nodes (which is not really that clean of a split in reality because NodePatchParser implement its own patch_node_config method that applies patches to node configs specifically). Most of the complexity is in creating a patch rather than 'applying' it, and this split requires changes to patching functionality in multiple places each time a new patch attribute is introduced. Additionally, this makes the PatchParsers difficult to test because applying actual result of their processing is mocked out.
Let's move the Node.patch methods into the respective PatchParsers instead to consolidate overall patching logic. We should also consider creating a separate ParsedModelPatch for model-specific configs that are patched by ModelPatchParser if possible (could be tricky with the inheritance currently in place).
The text was updated successfully, but these errors were encountered:
github-actionsbot
changed the title
Move ParsedNode.patch and Macro.patch to respective PatchParsers
[CT-2459] Move ParsedNode.patch and Macro.patch to respective PatchParsers
Apr 21, 2023
Currently a couple node types (Macro, ParsedNode) implement their own
patch
method which accepts a patch (either ParsedNodePatch or ParsedMacroPatch) and are responsible for applying the contents of the patch to the node attributes. The PatchParsers then call these nodepatch
methods once after constructing a patch.This splits the overall patching responsibilities into creating a patch and applying it across the PatchParsers and Nodes (which is not really that clean of a split in reality because NodePatchParser implement its own
patch_node_config
method that applies patches to node configs specifically). Most of the complexity is in creating a patch rather than 'applying' it, and this split requires changes to patching functionality in multiple places each time a new patch attribute is introduced. Additionally, this makes the PatchParsers difficult to test because applying actual result of their processing is mocked out.Let's move the Node.patch methods into the respective PatchParsers instead to consolidate overall patching logic. We should also consider creating a separate ParsedModelPatch for model-specific configs that are patched by ModelPatchParser if possible (could be tricky with the inheritance currently in place).
The text was updated successfully, but these errors were encountered: