Why isn't my Stringer interface method getting invoked? When using fmt.Println

前端 未结 6 1768
既然无缘
既然无缘 2020-12-12 16:31

Suppose I have the following code:

package main

import \"fmt\"

type Car struct{
    year int
    make string
}

func (c *Car)String() string{
    return fm         


        
相关标签:
6条回答
  • 2020-12-12 16:43

    When calling fmt.Println, myCar is implicitly converted to a value of type interface{} as you can see from the function signature. The code from the fmt package then does a type switch to figure out how to print this value, looking something like this:

    switch v := v.(type) {
    case string:
        os.Stdout.WriteString(v)
    case fmt.Stringer:
        os.Stdout.WriteString(v.String())
    // ...
    }
    

    However, the fmt.Stringer case fails because Car doesn't implement String (as it is defined on *Car). Calling String manually works because the compiler sees that String needs a *Car and thus automatically converts myCar.String() to (&myCar).String(). For anything regarding interfaces, you have to do it manually. So you either have to implement String on Car or always pass a pointer to fmt.Println:

    fmt.Println(&myCar)
    
    0 讨论(0)
  • 2020-12-12 16:45

    It's only related to implementation of fmt instead of Go however.

    String() with pointer receiver would be invoked by https://github.com/davecgh/go-spew since spew print things in this way:

    v = reflect.ValueOf(arg)
    
    ...
    
    switch iface := v.Interface().(type) {
        case fmt.Stringer:
            defer catchPanic(w, v)
            if cs.ContinueOnMethod {
                w.Write(openParenBytes)
                w.Write([]byte(iface.String()))
                w.Write(closeParenBytes)
                w.Write(spaceBytes)
                return false
            }
            w.Write([]byte(iface.String()))
            return true
        }
    
    0 讨论(0)
  • 2020-12-12 16:47

    Methods

    Pointers vs. Values

    The rule about pointers vs. values for receivers is that value methods can be invoked on pointers and values, but pointer methods can only be invoked on pointers. This is because pointer methods can modify the receiver; invoking them on a copy of the value would cause those modifications to be discarded.

    Therefore, for your String method to work when invoked on both pointers and values, use a value receiver. For example,

    package main
    
    import "fmt"
    
    type Car struct {
        year int
        make string
    }
    
    func (c Car) String() string {
        return fmt.Sprintf("{make:%s, year:%d}", c.make, c.year)
    }
    
    func main() {
        myCar := Car{year: 1996, make: "Toyota"}
        fmt.Println(myCar)
        fmt.Println(&myCar)
    }
    

    Output:

    {make:Toyota, year:1996}
    {make:Toyota, year:1996}
    
    0 讨论(0)
  • 2020-12-12 16:56

    Define your fmt.Stringer on a pointer receiver:

    package main
    
    import "fmt"
    
    type Car struct {
            year int
            make string
    }
    
    func (c *Car) String() string {
            return fmt.Sprintf("{maker:%s, produced:%d}", c.make, c.year)
    }
    
    func main() {
            myCar := Car{year: 1996, make: "Toyota"}
            myOtherCar := &Car{year: 2013, make: "Honda"}
            fmt.Println(&myCar)
            fmt.Println(myOtherCar)
    }
    

    Playground


    Output:

    {maker:Toyota, produced:1996}
    {maker:Honda, produced:2013}    
    

    Then, always pass a pointer to instances of Car to fmt.Println. This way a potentially expensive value copy is avoided under your control.

    0 讨论(0)
  • 2020-12-12 16:59

    Generally speaking, it's best to avoid assigning values to variables via static initializers, i.e.

    f := Foo{bar:1,baz:"2"}
    

    This is because it can create exactly the complaint you're talking about, if you forget to pass foo as a pointer via &foo or you decide to use value receivers you end up making a lot of clones of your values.

    Instead, try to assign pointers to static initializers by default, i.e.

    f := &Foo{bar:1,baz:"2"}
    

    This way f will always be a pointer and the only time you'll get a value copy is if you explicitly use value receivers.

    (There are of course times when you want to store the value from a static initializer, but those should be edge cases)

    0 讨论(0)
  • 2020-12-12 17:05

    The OP further asked:

    OP: [when a value receiver is used] "Does this basically mean that if I have a large struct, then every time it goes through Println it will be copied?"

    The following experiment is evidence that the answer is "yes" (when a value receiver is used). Note that the String() method increments the year in this experiment, and check how this affects the printed output.

    type Car struct {
        year int
        make string
    }
    
    func (c Car) String() string {
        s := fmt.Sprintf("{ptr:%p, make:%s, year:%d}", c, c.make, c.year)
        // increment the year to prove: is c a copy or a reference?
        c.year += 1
        return s
    }
    
    func main() {
        myCar := Car{year: 1996, make: "Toyota"}
        fmt.Println(&myCar)
        fmt.Println(&myCar)
        fmt.Println(myCar)
        fmt.Println(myCar)
    }
    

    With a value receiver (c Car), the following printed output shows that Go makes value copies of the Car struct, because the year increment is not reflected in subsequent calls to Println:

    {ptr:%!p(main.Car={1996 Toyota}), make:Toyota, year:1996}
    {ptr:%!p(main.Car={1996 Toyota}), make:Toyota, year:1996}
    {ptr:%!p(main.Car={1996 Toyota}), make:Toyota, year:1996}
    {ptr:%!p(main.Car={1996 Toyota}), make:Toyota, year:1996}
    

    Changing the receiver to a pointer (c *Car) but changing nothing else, the printed output becomes:

    {ptr:0xc420094020, make:Toyota, year:1996}
    {ptr:0xc420094020, make:Toyota, year:1997}
    {1998 Toyota}
    {1998 Toyota}
    

    Even when a pointer is provided as argument in a call to Println, i.e. fmt.Println(&myCar), Go still makes a value copy of the Car struct when a value receiver is used. The OP wants to avoid value copies being made, and my conclusion is that only pointer receivers satisfy that requirement.

    0 讨论(0)
提交回复
热议问题