Re: [go-nuts] Re: Struct members, hide or export?
On Thu, Aug 9, 2018 at 8:14 PM Manlio Perillo 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.
[go-nuts] Re: Struct members, hide or export?
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.
[go-nuts] Re: Struct members, hide or export?
Hi
I would suggest to use the second option. If you export all possible
members, you have to care on every redesign who and how this members are
used. This makes a redesign unnecessarily tricky.
Constructor functions are a common pattern in go code and therefore you
should not flinch to use it. For testing you can append "_test" to the
package name and then your test can't see any non exportet members of your
package.
Cheers
Sandro
Am Donnerstag, 9. August 2018 09:50:55 UTC+2 schrieb Jay G:
>
> 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*
>
>
> Is constructor actually anti-pattern in Go?
>
> type Foo struct {
> A A
> B B
> }
>
>
> func main() {
> _ := {A: myA, B: myB}
> }
>
> vs
>
> type Foo struct {
> a A
> b B
> }
>
>
> func NewFoo(a A, b B) *Foo {
> return {a: a, b: b}
> }
>
>
> func main() {
> _ := NewFoo(myA, myB)
> }
>
>
> thanks a lot!
> - J
>
--
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.
