Hacker News Reader

Comment by jonathanlydall | Hacker News Reader

I primarily work in C# and access modifiers allow me to constrain which types or their members on it are accessible to other types or assemblies.

This is particularly useful when authoring libraries as I know that for anything not public, I can refactor to my hearts content (provided the externally observed behaviour is otherwise unchanged).

It’s a bit of a pity that it was only relatively recently that Visual Studio changed the template for new classes to use internal instead of public.

There are lots of public classes in codebases I work on which are probably only public due to the old default and not used externally so could be refactored, but it’s hard to be sure.

Whereas with internal classes I can be sure (unless someone has used reflection, but then that’s their problem).

View on HN

I also wish 'sealed' was the default for classes in templates. Usually you're not thinking about what will happen if someone shows up 5 years later to derive from a random class you created, and it has performance benefits to seal a type. You can always remove the sealed qualifier later on purpose.

Same here. I recently came across a real use for the newer `private protected` (`FamANDAssembly`) modifier combo. Only derived types that are internal to my assembly can access this member. Beautiful. It re-confirmed my long standing belief that OOP is an incredibly powerful and valid pattern.

I'm assuming this is akin to Rust's pub(crate) keyword?

`internal` maps to `pub(crate)`. But there's no analog for `protected` because Rust doesn’t have inheritance.

`private protected` means "only me or anyone inheriting me in this assembly". There's also `protected internal` which means "me, anyone inheriting me, and anyone inside this assembly". An assembly is analogous to a Rust crate.

It's telling that you worded this as a writer of an API, not as a consumer.

Note that only a consumer of your apis can evaluate how well designed they are.

Yeah, I am sure that some fo the users may have higher skill set than authors. But majority of users suck at designing. And would add more fuel to the problems. And any refactoring efforts

I think this is not about your skill set, this is about use cases that the author of the library could not anticipate.

make everything immutable and then it doesn’t matter :)

Yes, it does matter even in functionally pure languages.

If the inner structure of your API's types are visible to callers, that's now part of your API, because callers can and will start to rely on that specific representation. Now you're constrained from updating your API, in order not to break code which depends on it.

Tell me you haven't written a large library for a wide array of users (many of which you wouldn't trust with a potato peeler) without telling me

Reply on news.ycombinator.com