Come to think of it, that might actually just be the answer you are looking for: C and Go are the same, in terms of visibility rules they allow. Any identifier in the namespace is either unexported (static in C) and visible to exactly this compilation unit, or it's exported (not static, in C) and exposed to other compilation units. The only difference is that Go allows, for convenience, that compilation unit to be split into multiple files and calls it a package. So, coming from C, this is a very natural delineation to choose.
On Tue, Jan 21, 2020 at 1:23 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > 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/CAEkBMfG6qAqN%2BkT4a5Vto0-mSJkWTYX-GdbHinzvAuCcMkNPgA%40mail.gmail.com.
