[go-nuts] Re: method resolution order
Thank you for your effort! It's not so much about terminology but more
about avoiding duplicate code.
And a way to do that is abstraction and specialization (has not necessarly
something to do with inheritance).
So after your explanation I would then
- factor everything from NotInS which can be done on the abstraction level
of T out
- implement NotInS as well in S utilizing the provided functionality of T
and adding its own "specialication"
On Wednesday, 16 September 2020 at 12:13:05 UTC+3 Volker Dobler wrote:
> On Wednesday, 16 September 2020 at 10:51:27 UTC+2 stephan...@gmail.com
> wrote:
>
>> Assume a public interface I with two methods NotInS and M whereas NotInS
>> is calling M. An implementation i of I which implements NotInS and M as
>> well as a specialization s of i which only implements M. Finally a
>> constructor whose return-type is I returns a pointer to an instance of
>> s. Calling on this return-value NotInS will execute i.M() as the
>> following test shows. I would like it to call s.M(). How would I do
>> this in a goish way? Thanks for any help!
>>
>
> Well, start of by not using Java/C#/C++ terminology as Go is different
> and in Go you simply cannot have a "specialization s of i" as there are
> no "specialization" as there is no inheritance. Also let's rewrite the code
> to be a bit more Go'ish:
>
> package main
>
> import "fmt"
>
> type I interface {
> NotInS()
> M()
> }
>
> type T struct{}
> func (t *T) NotInS() { t.M() }
> func (t *T) M() { fmt.Println("T.M") }
>
> type S struct{ *T }
> func (s *S) M() { fmt.Println("S.M") }
>
> func main() {
> x := {{}}
> x.NotInS()
> }
>
> You see S has no method NotInS defined and all calls to
> NotInS are automatically directed to implicit field T of
> S. Remember that embedding a *T in an S has nothing to
> do with inheritance or specialisation. It is just some tiny
> syntactic sugar for an implicit field and automatic method
> forwarding to that field. Spelling it out your code is
> equivalent to:
> type S struct{ T *T }
> func (s *S) NotInS() { s.T.M() }
>
> The embedded T doesn't know it is a field of S and you
> call T's M method and it is simply impossible to have
> S's M method called like this.
>
> You must redesign. Embedding is not inheritance and
> you cannot modle inheritance based design with embedding
> no matter how hard you try.
>
> V.
>
>
--
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/a6acbe9c-ebf4-4de4-b92a-33d0fc8ff1c8n%40googlegroups.com.
Re: [go-nuts] Re: method resolution order
Yes, it's sort of like asking what the best way to translate "This
sentence is not Spanish." into Spanish; you can do it, but it doesn't
make a lot of sense.
On Wed, 2020-09-16 at 02:13 -0700, Volker Dobler wrote:
> On Wednesday, 16 September 2020 at 10:51:27 UTC+2
> stephan...@gmail.com wrote:
> > Assume a public interface I with two methods NotInS and M whereas
> > NotInS
> > is calling M. An implementation i of I which implements NotInS and
> > M as
> > well as a specialization s of i which only implements M. Finally a
> > constructor whose return-type is I returns a pointer to an instance
> > of
> > s. Calling on this return-value NotInS will execute i.M() as the
> > following test shows. I would like it to call s.M(). How would I
> > do
> > this in a goish way? Thanks for any help!
>
> Well, start of by not using Java/C#/C++ terminology as Go is
> different
> and in Go you simply cannot have a "specialization s of i" as there
> are
> no "specialization" as there is no inheritance. Also let's rewrite
> the code
> to be a bit more Go'ish:
>
> package main
>
> import "fmt"
>
> type I interface {
> NotInS()
> M()
> }
>
> type T struct{}
> func (t *T) NotInS() { t.M() }
> func (t *T) M() { fmt.Println("T.M") }
>
> type S struct{ *T }
> func (s *S) M() { fmt.Println("S.M") }
>
> func main() {
> x := {{}}
> x.NotInS()
> }
>
> You see S has no method NotInS defined and all calls to
> NotInS are automatically directed to implicit field T of
> S. Remember that embedding a *T in an S has nothing to
> do with inheritance or specialisation. It is just some tiny
> syntactic sugar for an implicit field and automatic method
> forwarding to that field. Spelling it out your code is
> equivalent to:
> type S struct{ T *T }
> func (s *S) NotInS() { s.T.M() }
>
> The embedded T doesn't know it is a field of S and you
> call T's M method and it is simply impossible to have
> S's M method called like this.
>
> You must redesign. Embedding is not inheritance and
> you cannot modle inheritance based design with embedding
> no matter how hard you try.
>
> V.
>
> --
> 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/27f6fcb8-2040-491a-8309-85629d02406bn%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/7304cd1474813aa9da3fe0b27ee39fc8bf8d0f8c.camel%40kortschak.io.
[go-nuts] Re: method resolution order
On Wednesday, 16 September 2020 at 10:51:27 UTC+2 stephan...@gmail.com
wrote:
> Assume a public interface I with two methods NotInS and M whereas NotInS
> is calling M. An implementation i of I which implements NotInS and M as
> well as a specialization s of i which only implements M. Finally a
> constructor whose return-type is I returns a pointer to an instance of
> s. Calling on this return-value NotInS will execute i.M() as the
> following test shows. I would like it to call s.M(). How would I do
> this in a goish way? Thanks for any help!
>
Well, start of by not using Java/C#/C++ terminology as Go is different
and in Go you simply cannot have a "specialization s of i" as there are
no "specialization" as there is no inheritance. Also let's rewrite the code
to be a bit more Go'ish:
package main
import "fmt"
type I interface {
NotInS()
M()
}
type T struct{}
func (t *T) NotInS() { t.M() }
func (t *T) M() { fmt.Println("T.M") }
type S struct{ *T }
func (s *S) M() { fmt.Println("S.M") }
func main() {
x := {{}}
x.NotInS()
}
You see S has no method NotInS defined and all calls to
NotInS are automatically directed to implicit field T of
S. Remember that embedding a *T in an S has nothing to
do with inheritance or specialisation. It is just some tiny
syntactic sugar for an implicit field and automatic method
forwarding to that field. Spelling it out your code is
equivalent to:
type S struct{ T *T }
func (s *S) NotInS() { s.T.M() }
The embedded T doesn't know it is a field of S and you
call T's M method and it is simply impossible to have
S's M method called like this.
You must redesign. Embedding is not inheritance and
you cannot modle inheritance based design with embedding
no matter how hard you try.
V.
--
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/27f6fcb8-2040-491a-8309-85629d02406bn%40googlegroups.com.
