-
-
Notifications
You must be signed in to change notification settings - Fork 121
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
Don't show internal types by default #128
Comments
Yeah this is a good idea. I still personally prefer the default to be fully open though. A main use of the site for me is to see people's implementations and judge whether I want to use their code. But I understand that you may just want the public API too so a switch sounds reasonable to me. |
I understand that everyone has their own preferred practices, but this doesn't make much sense to me. You can't really see people's implementations this way— you can just see what they named some non-public types and methods, so at best you can make judgments about some aspects of their style. I'd be very surprised if many other developers using FuGet consider that to be "a main use." But even if a lot of people felt that was useful, I'd still be opposed to making it the default, since having internal symbols be visible is totally inconsistent with how assemblies work when you use them programmatically. |
I tend to agree with @eli-darkly. I like to use FuGet to explore the public API the author intends for me to use and including internal types and members makes it harder to discover what's exposed. With just the public types visible by default users can still inspect the implementation of public types and all their members by looking at the decompiled source. If a user needs to dig deeper then toggling seeing internal symbols could still be used. |
Internal-scoped types in an assembly are by definition not usable from outside the assembly (unless there's an InternalsVisibleTo directive) and are likely to be implementation details. It's nice to have the ability to see the full contents of the DLL if you really want to, but for normal usage these are just clutter that distracts from the API, even if they're grayed out.
The text was updated successfully, but these errors were encountered: