On Tue, Jan 21, 2020 at 12:04 PM Orson Cart <objectivedynam...@gmail.com> wrote:
> I'm still new to using Go so maybe I'm missing something of the 'culture' > but I find that I'd often like to be able to hide implementation detail on > a level that is more finely grained than the package. > […] > If as I suspect there is no way of achieving what I'm looking for, does > anyone know of a good reason why this level of information hiding isn't > possible in Go? Do experienced Go developers just not feel the need for it? > I don't really give much about the dichotomy of "experienced" Go developers vs. unexperienced ones, but I can say that I never felt the need. To the degree that I think it would be useful to turn this around: Why *do* you feel that need? What is the problem you are trying to solve, with just, say, using a rule that you are not touching other type's unexported fields or methods outside that type's methods? You also mention C, but note that C doesn't allow anything like this (even less so than Go), if you think about it. It's just that in C, the unit of compilation is a file, not a package. So you don't actually *have* anything like "peer" source files. Every file is its own unit and if you want to interact with values, you need to tell the compiler how they look. But there is no actual access-restriction put on anything. Even if a package intends for something to be an opaque pointer, you can always just add a type-def for that type and still access all its fields. Go allows this too, of course, using unsafe. But the Go notion of a "package" of related source files with shared visibility just doesn't exist in C. You can restrict things to a single file (by declaring them static), but that's it. If it's not static, it can be used from *any* other file linked into the final binary in exactly the same way. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFvcgzrDXjzf6FWhDPYDz_waD_0ZjaS%3DyLik%2BJU9fpaag%40mail.gmail.com.
