On Thursday, August 9, 2018 at 9:50:55 AM UTC+2, Jay G wrote: > > Let's say I'm writing some library for internal usage in my project, > what's the idiomatic way to design visibility of struct members? > > - Option 1. export structs and members as much as possible. Only hide > ones that need to be protected, e.g. by a lock > - Option 2. hide as much as possible. Only export when necessary > > *Opt 1 makes testing easier when written in separate pkg. Also we don't > rely on constructors to inject dependencies* > *Opt 2 defines a clearer API, and prevent users from accessing unnecessary > fields, which could be prone of error* > > The words "internal usage" and "users accessing the api" are in contradictions.
For internal usage I assume a package inside an "internal" directory. > [...] Manlio -- 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. For more options, visit https://groups.google.com/d/optout.
