Right now we have some hook fields that should never be changed externally like skip_output. We should make these fields private so that the user can't toggle them and break the parsing logic that depends on them within the context of the hooks using them (ie block/match).
For sure applies to skip_output as this can be toggled already via the hook's call input but should also be applied to args / kwargs potentially as again, these are already toggleable via the hook call's input and thus to A, reduce confusion and B, make sure it is clear that this is not a field that we want to let a user change we should set to private.
Mind that this does not fix any bug specifically as these inputs are already parsed out of the hook call input so they never make it into the hook's instantiation. Making them private only makes things more clear. It also introduces some difference between a dcl hook's definition and and a python hooks definition and so are not entirely ideal.
Right now we have some hook fields that should never be changed externally like
skip_output. We should make these fields private so that the user can't toggle them and break the parsing logic that depends on them within the context of the hooks using them (ie block/match).For sure applies to
skip_outputas this can be toggled already via the hook's call input but should also be applied toargs/kwargspotentially as again, these are already toggleable via the hook call's input and thus to A, reduce confusion and B, make sure it is clear that this is not a field that we want to let a user change we should set to private.Mind that this does not fix any bug specifically as these inputs are already parsed out of the hook call input so they never make it into the hook's instantiation. Making them private only makes things more clear. It also introduces some difference between a dcl hook's definition and and a python hooks definition and so are not entirely ideal.
Maybe don't worry about this.