Grokbase › Groups › Go › golang-nuts › January 2014
FAQ
C Banning has it right.
In Go, you write a *function* (not a method, function) that takes an
interface as a parameter. Boom, polymorphism.
For an example in the std lib (one of hundreds, possibly) look at
fmt.Printf. It's a package-level, free-standing function. Notice its first
parameter - an io.Writer - an interface type. That's how it's done.

Trying to code Go if your only way of thinking is "Java" will be about as
successful as coding Haskell like you code C.
Different languages have different patterns and idioms.
On Sunday, March 18, 2012 12:26:23 PM UTC-6, trialcodr wrote:

Any idea why this code calls A.Foo() even though Bar() is called on a
value of type B?

package main

import (
"fmt"
)

type A struct {
}

func (a *A) Foo() {
fmt.Println("A.Foo()")
}

func (a *A) Bar() {
a.Foo()
}

type B struct {
A
}

func (b *B) Foo() {
fmt.Println("B.Foo()")
}

func main() {
b := B{A: A{}}
b.Bar()
}
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • DV at Jan 22, 2014 at 5:18 pm ⇧
    Gah. I meant fmt.Fprintf for my specific example. Although fmt.Printf works
    just as well as an example, I suppose.
    On Wednesday, January 22, 2014 10:16:35 AM UTC-7, DV wrote:

    C Banning has it right.
    In Go, you write a *function* (not a method, function) that takes an
    interface as a parameter. Boom, polymorphism.
    For an example in the std lib (one of hundreds, possibly) look at
    fmt.Printf. It's a package-level, free-standing function. Notice its first
    parameter - an io.Writer - an interface type. That's how it's done.

    Trying to code Go if your only way of thinking is "Java" will be about as
    successful as coding Haskell like you code C.
    Different languages have different patterns and idioms.
    On Sunday, March 18, 2012 12:26:23 PM UTC-6, trialcodr wrote:

    Any idea why this code calls A.Foo() even though Bar() is called on a
    value of type B?

    package main

    import (
    "fmt"
    )

    type A struct {
    }

    func (a *A) Foo() {
    fmt.Println("A.Foo()")
    }

    func (a *A) Bar() {
    a.Foo()
    }

    type B struct {
    A
    }

    func (b *B) Foo() {
    fmt.Println("B.Foo()")
    }

    func main() {
    b := B{A: A{}}
    b.Bar()
    }
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Xingtao zhao at Jan 22, 2014 at 9:51 pm ⇧
    Yes, it is right when there is only one such function. But when there are
    many such functions, I think the wrapper style will be better. For example,
    matrix.Interface just implement any functions that will be overridden by
    different matrix types, and we leave the common functions on all matrix
    types to Matrix:

    type Interface {
         Size() (r, c int)
         At(r, c int) float64
         Set(r, c int, v float64)
    }

    type Matrix {
         Interface
    }

    func (m Matrix) Add(n Matrix) Matrix { ... }
    func (m Matrix) Mult(s float64) Matrix { ... }
    ...

    In this case, it will convenient to define functions on Matrix and expose
    Matrix to public, instead of a list of independent functions that accept
    Interface.

    While in the traditional OOP (java, c++), we would define a basic Matrix
    class with the virtual functions, and some common functions, and the
    subclasses will override the virtual functions of basic Matrix. While in
    Go, we can do it by the way above.
    On Wednesday, January 22, 2014 9:16:35 AM UTC-8, DV wrote:

    C Banning has it right.
    In Go, you write a *function* (not a method, function) that takes an
    interface as a parameter. Boom, polymorphism.
    For an example in the std lib (one of hundreds, possibly) look at
    fmt.Printf. It's a package-level, free-standing function. Notice its first
    parameter - an io.Writer - an interface type. That's how it's done.

    Trying to code Go if your only way of thinking is "Java" will be about as
    successful as coding Haskell like you code C.
    Different languages have different patterns and idioms.
    On Sunday, March 18, 2012 12:26:23 PM UTC-6, trialcodr wrote:

    Any idea why this code calls A.Foo() even though Bar() is called on a
    value of type B?

    package main

    import (
    "fmt"
    )

    type A struct {
    }

    func (a *A) Foo() {
    fmt.Println("A.Foo()")
    }

    func (a *A) Bar() {
    a.Foo()
    }

    type B struct {
    A
    }

    func (b *B) Foo() {
    fmt.Println("B.Foo()")
    }

    func main() {
    b := B{A: A{}}
    b.Bar()
    }
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • C Banning at Jan 23, 2014 at 3:18 pm ⇧
    http://golang.org/pkg/sort/#Interface
    On Wednesday, January 22, 2014 3:51:00 PM UTC-6, xingtao zhao wrote:

    Yes, it is right when there is only one such function. But when there are
    many such functions, I think the wrapper style will be better. For example,
    matrix.Interface just implement any functions that will be overridden by
    different matrix types, and we leave the common functions on all matrix
    types to Matrix:

    type Interface {
    Size() (r, c int)
    At(r, c int) float64
    Set(r, c int, v float64)
    }

    type Matrix {
    Interface
    }

    func (m Matrix) Add(n Matrix) Matrix { ... }
    func (m Matrix) Mult(s float64) Matrix { ... }
    ...

    In this case, it will convenient to define functions on Matrix and expose
    Matrix to public, instead of a list of independent functions that accept
    Interface.

    While in the traditional OOP (java, c++), we would define a basic Matrix
    class with the virtual functions, and some common functions, and the
    subclasses will override the virtual functions of basic Matrix. While in
    Go, we can do it by the way above.
    On Wednesday, January 22, 2014 9:16:35 AM UTC-8, DV wrote:

    C Banning has it right.
    In Go, you write a *function* (not a method, function) that takes an
    interface as a parameter. Boom, polymorphism.
    For an example in the std lib (one of hundreds, possibly) look at
    fmt.Printf. It's a package-level, free-standing function. Notice its first
    parameter - an io.Writer - an interface type. That's how it's done.

    Trying to code Go if your only way of thinking is "Java" will be about as
    successful as coding Haskell like you code C.
    Different languages have different patterns and idioms.
    On Sunday, March 18, 2012 12:26:23 PM UTC-6, trialcodr wrote:

    Any idea why this code calls A.Foo() even though Bar() is called on a
    value of type B?

    package main

    import (
    "fmt"
    )

    type A struct {
    }

    func (a *A) Foo() {
    fmt.Println("A.Foo()")
    }

    func (a *A) Bar() {
    a.Foo()
    }

    type B struct {
    A
    }

    func (b *B) Foo() {
    fmt.Println("B.Foo()")
    }

    func main() {
    b := B{A: A{}}
    b.Bar()
    }
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 22, '14 at 5:16p
activeJan 23, '14 at 3:18p
posts4
users3
websitegolang.org

3 users in discussion

DV: 2 posts Xingtao zhao: 1 post C Banning: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase