I agree with all of your points, but my agreements are orthogonal to my original points.

The crux of my point is that these .NET and C# idioms needs to change.

In python, yes, callers of “privates” know that they are messing with something that they shouldn’t by naming convention. Its far easier than using reflection.

The key is that the value added by this ease is greater than the value added by making it difficult using the private keyword. For evidence, see python and ruby.

By following this convention you can still change your implementation details without breaking callers. If they have deliberately used something with private naming convention, that is still their own fault. You can still take responsibility for keeping your own public API (and ABI) stable.

It is a matter of, “Simple things should be simple. Hard things should be possible”

If it isn’t clear yet, I am not advocating for everything public and that is all. I’m advocating for everything public with a convention (or maybe even interface) based approach to defining the public API. The private API should still be there for all the uses the original developer never considered. The consuming developer knows that “there be dragons.”

I disagree strongly.

Yes, callers can circumvent access control via reflection – but then they’re *knowingly* messing with something that they obviously shouldn’t.

I should be able to change my implementation details without breaking callers. If they’ve deliberately messed around with reflection, that’s their own fault – but I take responsibility for keeping my public API stable. This isn’t a matter of what’s advanced and what’s not – it’s a matter of what’s meant to be relied on and what isn’t.