In the existing NMT implementation, there is a configuration option called IgnoreMaxNamespace that, when enabled, enforces a customized approach for determining a node's namespace range using its left and right children (please see the HashNode). However, this particular feature negatively affects code readability and maintainability. Additionally, it has led to confusion and raised questions among those encountering this logic for the first time. To address these issues, it is necessary to refactor the NMT implementation and elevate it to higher-level business logic, rather than keeping it within the NMT implementation itself.
Proposal
One potential approach involves revising the NMT constructor's signature to include a parameter that accepts a function. This function would take the namespaces of the left and right children and specify the namespace range of the parent node. Subsequently, this function can be utilized during the computation of node hashes.
Problem
In the existing NMT implementation, there is a configuration option called
IgnoreMaxNamespacethat, when enabled, enforces a customized approach for determining a node's namespace range using its left and right children (please see theHashNode). However, this particular feature negatively affects code readability and maintainability. Additionally, it has led to confusion and raised questions among those encountering this logic for the first time. To address these issues, it is necessary to refactor the NMT implementation and elevate it to higher-level business logic, rather than keeping it within the NMT implementation itself.Proposal
One potential approach involves revising the NMT constructor's signature to include a parameter that accepts a function. This function would take the namespaces of the left and right children and specify the namespace range of the parent node. Subsequently, this function can be utilized during the computation of node hashes.