-
Notifications
You must be signed in to change notification settings - Fork 746
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
Should we move ISystemClock to Primitives? #151
Comments
shrug we keep talking about it but never found a reason to do it. |
Meh. It's so tiny we'd just be adding more spaghetti. |
The clock interface is always testing purposes. IMO unless we need different clock implementations at runtime, it doesn't provide value as an API. |
Yeah it's always just for testing. And it's like 10 lines of code. And it never changes. |
Real world apps (see where I am looking at) need this abstraction. But because it's not in Primitives we'll have to do our own, like we did by the past. |
Fixed misspelled words in comments and a few method names in Samples projects
Addresses a usability issue where typed clients with generic type parameters didn't work well. This is broken because Type.Name always uses the metadata name 'MyClientType`1' instead of the name that the user typed in code. This change uses some existing infrastructure we have to 'pretty print' the type name. The subtle breaking change here is that if you were using `services.Configure(typeof(MyClient<>).Name, ...)` this will no longer work. Doing these operations through the builder we provide will work just fine, so I'm not terribly concerned.
I would like this abstraction as well |
We use it as a way for testing and have copies of that interface in multiple places
I'm adding one to FileSystem to add testing support for polling. Should we commonize it Microsoft.Extensions.Primitives? That said, it's not a whole lot of code to replicate so there isn't a lot of benefit to commonizing it.
The text was updated successfully, but these errors were encountered: