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.

Reply via email to