Github user ahgittin commented on the issue:
    Implementation-wise I suggest we deprecate `InheritanceMode` in favour of a 
new `StandardInheritanceModes` whose constructors set the values above, with 
the following upgrade patterns:
    InheritanceMode.NONE = // one of these two depending on context
        // this should probably be the more common
        // (fixes the issue observed today with software process commands)
        // but for backwards compatibility we'll set it equal to this mode 
(with a warning)
    InheritanceMode.IF_NO_EXPLICIT_VALUE =
    InheritanceMode.DEEP_MERGE =
    We also change `ConfigInheritance` to be an interface with these new 
        /** used by callers to determine whether to export values for 
inheritance */
        boolean ConfigInheritance.isReinheritable(ConfigKey)
        /** returns the value respecting inheritance and using the defaultMode 
if keys do not define inheritance*/
        Object ConfigInheritance.resolve(@Nullable ConfigKey parentKey, 
@Nullable Object parentValue, @Nullable ConfigKey childKey, @Nullable Object 
childValue, @NonNull ConfigInheritance defaultMode);
    All old methods are deprecated.  `StandardInheritanceModes` 
implements`ConfigInheritance` and code is rewritten to use the new methods.  I 
think this will cut down on repeated code dealing with inheritance elsewhere 
and if ever needed allow different strategies to be applied.
    Big questions:
    * Does this sound sensible?
    * Are there any situations where we'd need more information than is 
currently passed to the proposed`resolve(...)` method?
    @sjcorbett @grkvlt @aledsage @neykov your feedback especially desired

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

Reply via email to