-
Notifications
You must be signed in to change notification settings - Fork 831
KeyValuePairSettings - IReadOnlyDictionary / latest setting win #1051
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
return Settings(new KeyValuePairSettings(settings)); | ||
|
||
var settingsDictionary = new ReadOnlyDictionary<string, string>(settings.ToDictionary(x => x.Key, x => x.Value)); | ||
return Settings(new KeyValuePairSettings(settingsDictionary)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Dictionary
implements IReadOnlyDictionary
in recent framework versions - I don't think the creation of the ReadOnlyDictionary
should be needed here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, that's true. It's one of those strange things where a writable dictionary actually implements read-only dictionary ....
I'm not sure what the "best practices" are in that regard, but I guess in internal classes there is no need to be a control-freak :)
I'll change that.
.Where(kvp => _supportedDirectives.Any(kvp.Key.StartsWith)) | ||
.ToDictionary(kvp => kvp.Key, kvp => kvp.Value); | ||
|
||
return new ReadOnlyDictionary<string, string>(directives); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here, if we don't create a ReadOnlyDictionary
explicitly, we can get this back to a one-liner and avoid the additional method.
(Nitpick - the codebase doesn't use explicit internal
modifiers elsewhere.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually the method exists for the sake of tests ... but I don't know if the test
+ [Fact]
+ public void IrrelevantKeysAreIgnored()
+ {
+ var irrelevantSettings = new Dictionary<string, string>()
+ {
+ ["whatever:foo:bar"] = "willBeIgnored",
+ ["irrelevant"] = "willBeIgnored",
+ };
+
+ var directives = KeyValuePairSettings.ExtractDirectives(irrelevantSettings);
+
+ Assert.False(directives.Any());
+ }
provides much value ...
(about internal
: dammit, I thought I had removed them all !)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, I didn't notice the test dependency, thanks 👍
4bb92f2
to
2784e27
Compare
Maybe it should also be mentioned in the documentation somewhere ... (or included in #1053 ) For now, I have left an overload |
Refactored KeyValuePairSettings to accept a IReadOnlyDictionary<string, string> instead of IEnumerable<KeyValuePair<string, string>> in order to reveal the fact that key-value settings are not lazily consumed. Added tests on edge cases : duplicate keys, irrelevant settings.
... and useless test
Instead, take the last value of each key, to remove work from future Serilog.Settings.Combined
d5f87b0
to
64e45ab
Compare
👍 |
new PR based on discussion #1047 (comment) .
Make
KeyValuePairSettings
accept aIReadOnlyDictionary<string, string>
instead of aIEnumerable<KeyValuePair<string, string>>
to make it more obvious that :This has no impact on the public API given that class
KeyValuePairSettings
isinternal
.This PR also adds a few tests around the edge cases