> Can the generic API be > > <T> ConfigKey<T> get(String paramName, Class<T> type); > > Just to be a little easier to use. I know the method is discouraged, but I > do so > some places it would be useful. Besides that I like it. > The contract is simple enough that the implementation can become quite > flexible.
A similar usage is already on the ConfigDepot interface. ConfigKey<?> get(String key); I can probably add a method with the exact same signature but really all it does will be check the type and cast. > > Scoped values seems a little strange though. Why do you define the scope in > the key? Why wouldn't you pass the scope when you call valueIn? Its seems > a bit odd. Because as the caller, you need to know what the Long is (is it a > zone id, pool id, etc.). So it seems more natural to pass valueIn(Scope.Zone, > 42) because it is very explicit to the caller. Also, why can't I have a key > that is > scoped at a different level depending on the calling context. That's a good question. I had the same question when I looked at the original implementation of scoped variables. The scope is defined in both the key and when getting value but they're always the same so essentially it's defined in the key and not the get value. I agree with your assessment that it's much more flexible to have the scope defined when getting the value, but since I'm mostly refactoring here, I didn't want to get too far away from the original intent of the scope code so I left the scope definition in the key for now. Maybe the original implementer can take a look to see if that flexibility makes sense for their requirements. I can see for example that at least the original implementation does not really have a true scope implementation where it checks cluster, then pod, then zone, then global. It only checked the scope that was defined in the key. It would have been much better if the scope in the key defined the depth of the scope and the scope in get value defined where to start search for the override within that depth. --Alex
