Does not spew any struct fields for me: about go-spew HOT 9 CLOSED

I have a question on the go-lang mailing list to see if there is a trick, but so far it seems impossible to tell if a String method was directly defined on the parent type or "inherited" from an embedded type. As a result, the only way to handle this situation is to enable the ContinueOnMethod option.

spew.Config.ContinueOnMethod = true

from go-spew.

Can you post your type declarations and example code that isn't working? I just tried the following, and as you can see it's working properly:

type Vec2 struct {
    X float64
    Y float64
}

type Vec3 struct {
    a uint16
    b uint32
}

type FrustumCoords struct {
    Vec2
    C, TL, TR, BL, BR Vec3
    x, y              Vec3
}

func main() {
    f := FrustumCoords{
        Vec2: Vec2{1.0, 2.0},
        C:    Vec3{3, 4},
        TL:   Vec3{5, 6},
        TR:   Vec3{7, 8},
        BL:   Vec3{9, 10},
        BR:   Vec3{11, 12},
        x:    Vec3{13, 14},
        y:    Vec3{15, 16},
    }
    spew.Dump(f)
}

And the output is:

(main.FrustumCoords) {
 Vec2: (main.Vec2) {
  X: (float64) 1,
  Y: (float64) 2
 },
 C: (main.Vec3) {
  a: (uint16) 3,
  b: (uint32) 4
 },
 TL: (main.Vec3) {
  a: (uint16) 5,
  b: (uint32) 6
 },
 TR: (main.Vec3) {
  a: (uint16) 7,
  b: (uint32) 8
 },
 BL: (main.Vec3) {
  a: (uint16) 9,
  b: (uint32) 10
 },
 BR: (main.Vec3) {
  a: (uint16) 11,
  b: (uint32) 12
 },
 x: (main.Vec3) {
  a: (uint16) 13,
  b: (uint32) 14
 },
 y: (main.Vec3) {
  a: (uint16) 15,
  b: (uint32) 16
 }
}

from go-spew.

I'm gonna whip up a small example program to reproduce this in Go 1.0.3.

The typedefs are:

Vec2 https://github.com/metaleap/go-util/blob/master/num/vec2.go

Vec3 https://github.com/metaleap/go-util/blob/master/num/vec3.go

FrustumCoords https://github.com/go3d/go-3dutil/blob/master/frustum.go

spew call https://github.com/go3d/go-ngine/blob/master/core/threading.go#L90

from go-spew.

Reproducable test program:

https://github.com/metaleap/go-misctools/blob/master/spewtest/main.go

Its output:

2013/03/13 08:53:36 RUN: go install github.com/metaleap/go-misctools/spewtest
2013/03/13 08:53:36 TOTAL BUILD TIME: 189.0108ms
2013/03/13 08:53:36 RUN: c:\gd\bin\spewtest
___________________________________________

{X:10.00 Y:20.00}
[Finished in 0.4s]

Changing from Printf() to Dump() gives the same issue:

(u3d.FrustumCoords) {X:10.00 Y:20.00}

Your move ;))

from go-spew.

Ok thanks for the example. The type in question embeds another type that has a String method on it. By default, once spew invokes a Stringer/error interface for a type, it does not recurse further. It appears to be assuming the Stringer on the embedded type is for the entire parent type.

I'll look at fixing this, but in the mean time, you can override this with:

spew.Config.ContinueOnMethod = true

Or, if you don't want to invoke any of the custom Stringers on the types, you can do:

spew.Config.DisableMethods = true

from go-spew.

"once spew invokes a Stringer/error interface for a type, it does not recurse further" -- this I didn't know and explains everything. Thanks!

from go-spew.

No problem. This is a legitimate bug though, so good find. It should be invoking the Stringer on Vec2, then going on to the next elements in the struct (C, TL, etc). I will get that fixed if possible. It's a little tricky since embedding the type causes the String interface to exist on the parent type too.

from go-spew.

Good to hear; now that it works for me, spew is awesome! Comes in so handy.

from go-spew.

I'm going to close this as a language limitation per the previous comment. As stated above, the workaround is to allow spew to continue when methods are invoked via the ContinueOnMethod option.

from go-spew.