The one way this could be possibly useful, in my opinion, would be to add
methods to existing interfaces (from other packages no less), a la
extensions in Objective-C (and Swift). So say
extending io.Reader {
ReadAll() ([]byte, error)
}
func (r io.Reader) ReadAll() ([]byte, error) {
// implementation than can use io.Reader methods on r but nothing else
}
and any type implementing io.Reader now has a ReadAll() method as well.
However, this is spooky action at a distance as it would be very unclear
att the call site where this ReadAll() might be defined... I could imagine
declaring it as a new interface:
interface ReadAller: io.Reader {
ReadAll() ([]byte, error)
}
func (r ReadAller) ReadAll() ([]byte, error) {
// implementation
}
Go now has inheritance! Of interfaces, at least... But then the caller
needs to cast the io.Reader to a ReadAller to use the method, which is no
more convenient than just calling the ioutil.ReadAll function to begin
with, and we have muddled the language for no reason.
So all in all, lets not. :)
//jb
ons 19 okt. 2016 kl 23:41 skrev Viktor Kojouharov <vkojouha...@gmail.com>:
>
> On Tuesday, October 18, 2016 at 9:27:36 PM UTC+3, Konstantin Khomoutov
> wrote:
>
> On Tue, 18 Oct 2016 11:11:59 -0700 (PDT)
>
> parais...@gmail.com wrote:
>
> > Obviously in Go this is a compile time error :
> >
> > type Foo interface {}
> >
> >
> > func (f Foo) DoSomething(){}
> >
>
> > I wonder if there is some technical limitations that make it
> > undesirable or hard to implement, or it's just that Go designers
> > didn't think it is a relevant feature.
> >
> > I personally think there is it could be handy in some situations,
> > instead of having to write a function without receiver, it could
> > allow to attach behavior to interfaces automatically
> > instead of the explicit :
> >
> > func DoSomething(f Foo){}
> >
> >
> > what is your opinion on the matter ? Unfortunately I wasn't able to
> > catch anyone of the Go team during the recent conference in Paris to
> > ask that question.
>
> type Foo interface {
> func DoSomething()
> }
>
> func (f Foo) DoSomething() {
> }
>
> var f Foo
>
> f.DoSomething()
>
> How do you propose to distinguish these two DoSomething()-s?
>
>
> That's just a default method implementation. There's nothing inherently
> confusing about what gets called. If a concrete implementation exists, that
> gets called, otherwise the default one does.
>
>
>
> More to the point: how could anyone infer what's about to get called
> from looking at that "f.DoSomething()" expression even if there could
> be no conflict as in my contrived example -- is it a call on an
> "interface itself" or on a concrete type an interface value contains?
>
> --
> 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.
>
--
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.
