On Thu, Aug 9, 2018 at 8:14 PM Manlio Perillo <manlio.peri...@gmail.com> wrote: > > > > 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.
users = other pkgs within project using this lib internal = not intended to be used by other projects > > For internal usage I assume a package inside an "internal" directory. yes thanks! - J > > > [...] > > Manlio > > -- > You received this message because you are subscribed to a topic in the Google > Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/iZMw82G-lMo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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.
