Description
Currently drivers can extend behavior two ways: declarative rules (via HConfigDriverRules) and imperative method overrides (idempotent_for(), swap_negation(), config_preprocessor()). This dual mechanism makes behavior harder to predict and prevents drivers from being fully serializable.
Proposed Change
Move all imperative overrides into the rule system:
Benefits
- All driver behavior lives in
HConfigDriverRules
- Drivers become fully serializable (could be loaded from YAML/JSON)
- Easier to test — no method mocking needed, just rule configuration
- Users can extend drivers without subclassing
Breaking Change
Yes — all drivers that override methods must be rewritten to use rules.
Description
Currently drivers can extend behavior two ways: declarative rules (via
HConfigDriverRules) and imperative method overrides (idempotent_for(),swap_negation(),config_preprocessor()). This dual mechanism makes behavior harder to predict and prevents drivers from being fully serializable.Proposed Change
Move all imperative overrides into the rule system:
IdempotentKeyExtractorRuleor similarswap_negation()→ unified negation rule system (v4: Unify negation rules into single NegationRule with strategy enum #220)config_preprocessor()→FullTextSubRuleor newPreprocessorRuleBenefits
HConfigDriverRulesBreaking Change
Yes — all drivers that override methods must be rewritten to use rules.