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/FF0701C3-2FEB-4BD7-BD60-EB39CDE7E6E2%40ix.netcom.com.