Skip to content
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

Does the Internal namespace need to have public members? #215

Open
TWhidden opened this issue Feb 29, 2024 · 2 comments
Open

Does the Internal namespace need to have public members? #215

TWhidden opened this issue Feb 29, 2024 · 2 comments

Comments

@TWhidden
Copy link

This is purely a selfish request - The ILoggerFactory is a common dotnet interface, which when using this library for anything will become the first-priority for selection. Downside is, it gets selected before the official MS libs if you are flying through code

image

Any chance those accessors could be marked internal instead of public? I am unsure why they would need to be exposed if they are in what most would say, an internal folder for lib internals only. Just my .02c, and again, purely selfish for my auto-complete sanity!

public interface ILoggerFactory

@MichaCo
Copy link
Owner

MichaCo commented Mar 10, 2024

The idea was to expose that interface so that a consumer can write a forwarding wrapper which could send log messages to the Microsoft.Extensions.Logging framework for example.
For that it has to be public. I agree that the name could have been slightly different to prevent the issue you see, but hey..

An internal directory can totally have public APIs, its in internal to indicate it might change and the APIs might not be stable forever.

But to your request, I do not really want to change this atm. Sorry ;)

@TWhidden
Copy link
Author

All good. Doesn't hurt to ask!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants