Thank you all for your feedback and input. Shame on me that I didn't look hard enough through the stdlib for getting some examples, but thanks Axel for pointing that out.
On Thu, Oct 10, 2019 at 3:11 AM Robert Engels <reng...@ix.netcom.com> wrote: > > Ugh. Every time I see that I cringe.... > > > On Oct 9, 2019, at 7:58 PM, burak serdar <bser...@computer.org> wrote: > > > > On Wed, Oct 9, 2019 at 5:48 PM 'Axel Wagner' via golang-nuts > > <golang-nuts@googlegroups.com> wrote: > >> > >> There's loads of precedence in the stdlib: > >> > >> https://godoc.org/net/http/#FileSystem.Open > >> https://godoc.org/net/http#File.Stat > >> https://godoc.org/net#Conn.LocalAddr > >> https://godoc.org/database/sql/driver/#Driver.Open > >> https://godoc.org/image#Image.ColorModel > >> https://godoc.org/reflect/#Type.Elem > >> And don't forget that error itself is an interface. > >> > >> Honestly, if you need it, go for it. There are definitely places where > >> it's over abstraction to do it, but I don't think there's a good or > >> universal rule you can use to decide which is which. > >> > >> FWIW, I tend to disagree with the "return structs, accept interfaces" > >> advise in general. If go had variant func/methods, that would be useful > >> guidance. But as it stands, it is too often necessary to violate it (every > >> usage of an error return value is in fact such a violation). And the > >> "accept interfaces" part tends to lead to over abstraction (I would > >> probably agree with "consider accepting interfaces if they already exist" > >> though). > > > > > > There is one point you need to remember when returning interfaces: > > make sure you handle nil correctly: > > > > type S struct {} > > > > type I interface {} > > > > func f() *S { > > return nil > > } > > > > func g() I { > > x:=f() > > return x > > } > > > > Above, g() is not nil. The correct code would be: > > > > func g(() I { > > x:=f() > > if x==nil { > > return nil > > } > > return x > > > > } > > > > > >> > >>> On Wed, Oct 9, 2019 at 9:39 AM Martin Palma <m...@palma.bz> wrote: > >>> > >>> I'm wondering If it is ok (or good Go code) if an interface method > >>> returns an other interface? Here an example: > >>> > >>> type Querier interface { > >>> Query() string > >>> } > >>> > >>> type Decoder interface { > >>> DecodeAndValidate() Querier > >>> } > >>> > >>> > >>> -- > >>> 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/531f29a6-ea2e-4416-a0d0-ce697dc7a09b%40googlegroups.com. > >> > >> -- > >> 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/CAEkBMfHHtn5t3TZOCG4xA_3kVbNqY2_xo7EtHoLyhi6P28ku9g%40mail.gmail.com. > > > > -- > > 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/CAMV2Rqp-n0UaxQVpPVgJKayNzY6Voe5QRL4n7MoqmQMavL3oiQ%40mail.gmail.com. > -- 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/CANMxC7BHfFNduYVqY8xnZyTL8oPzZ2r15ApeGRsVW60Xckswng%40mail.gmail.com.