Hacker News new | ask | show | jobs
by stevemk14ebr 1073 days ago
"What I got right...Using capitalization for the public/private distinction in functions, methods, variables, and fields"

I disagree with this strongly. Due to this when you need to change one of these things to the opposite it involves changing every use site as well. This has far reaching implications for refactoring, wrapping external code when you really do need to expose its guts, etc. Any time you need to do this in a non-manual fashion you're required to parse all of the code exactly perfectly (ASTs and such). Even go itself has not figured out how to do this, rf is still experimental and not complete: https://pkg.go.dev/rsc.io/rf.

Example use case: https://github.com/golang/go/issues/46792

I much prefer the non-viral public/private attributes other languages use.

2 comments

Short of changes within the module itself, if you switch a Public function to a private function in another language, how are you not having to go change everywhere it's being used?
I'd guess the typical situation is you had thought maybe a public API featuring enunciate_spools() was a good idea, but eventually you realised actually nobody actually wants to enunciate spools and few people know how, when you see other people's code that calls enunciate_spools, it's always either a bug (and they shouldn't have) or test code that is inappropriately testing your stuff not their stuff.

So you make it private, in say Rust that's an ABI break, so you need a semver bump, but you aren't changing your code. Internally normal_operation does need to enunciate spools, not to mention the acrobatic use of it in complex_operation and fancy_coroutine but that's because it knows intimately what spools are and why it's enunciating them - it's an internal design element, not an API.

In Go, you have to rename it everywhere. Maybe your tooling helps with that. OK, but, not having to do it also helps with that and for everybody.

Agreed. First thing I frowned at when considering Go. (Plus it looks a bit messy. foo.Init() ?).

That and reserving the verb `make`..