Deep printing in the reflect package

[aind...@gmail.com]

Often on my team, Go programmers (particularly new ones) simply want full visibility into a data structure when debugging. For those who aren't familiar with pointers, seeing a hexadecimal number show up in a log can be really frustrating. I usually point them to https://github.com/davecgh/go-spew or https://github.com/sanity-io/litter. Although they can be heavy-handed with their unsafe package dependency and fancy formatting, they are indispensable when debugging data structures like syntax trees.

I wonder it's worthwhile to add this functionality to the reflect package, and take advantage of the functionality that DeepEquals uses. I'm not a fan of Dump functions that just take an io.Writer. Why not add a named type for interface{} or reflect.Value called reflect.Deep, which implements fmt.Formatter? Then, packages that use fmt will have more precise control over formatting, and we can maybe add special formatting directives for reflect.Deep.

What do you think?

[Ian Lance Taylor]

Well, we already have fmt.Printf("%#v", value).

I don't see any obvious reason to add printing to the reflect package.
It doesn't require any internal information, and can be written
entirely separately. And, there will inevitably be a lot of desire
for customization of the printed output, which will lead to a complex
API.

Basically: https://golang.org/doc/faq#x_in_std .

Ian

[aind...@gmail.com]

I agree that this functionality can be implemented outside the standard library. However, traversing nested data structures does seem to fall into reflect's domain. In particular, one would have to deal with unexported fields and pointer cycles.

I can also see how a newcomer would think the standard library would be able to print any value in the language.

> there will inevitably be a lot of desire for customization of the printed output, which will lead to a complex API.

This is a fair. Maybe the goal should be to provide a general mechanism to walk data structures, rather than format them?

Akhil

[Ian Lance Taylor]

On Fri, Sep 4, 2020 at 2:57 PM aind...@gmail.com <aind...@gmail.com> wrote:
>
> I agree that this functionality can be implemented outside the standard library. However, traversing nested data structures does seem to fall into reflect's domain. In particular, one would have to deal with unexported fields and pointer cycles.
>
> I can also see how a newcomer would think the standard library would be able to print any value in the language.
>
> > there will inevitably be a lot of desire for customization of the printed output, which will lead to a complex API.
>
> This is a fair. Maybe the goal should be to provide a general mechanism to walk data structures, rather than format them?

Well, that too can live outside of the reflect package. Probably the
right approach would be write a third party package, see whether it
seems popular, and then consider whether to bring it into the standard
library.

You suggest that traversing nested data structure is reflect's domain,
but I'm not sure I agree. The only current case is reflect.DeepEqual.

Ian

> On Friday, September 4, 2020 at 4:24:23 PM UTC-4 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 4, 2020 at 1:11 PM aind...@gmail.com <aind...@gmail.com> wrote:
>> >
>> > Often on my team, Go programmers (particularly new ones) simply want full visibility into a data structure when debugging. For those who aren't familiar with pointers, seeing a hexadecimal number show up in a log can be really frustrating. I usually point them to https://github.com/davecgh/go-spew or https://github.com/sanity-io/litter. Although they can be heavy-handed with their unsafe package dependency and fancy formatting, they are indispensable when debugging data structures like syntax trees.
>> >
>> > I wonder it's worthwhile to add this functionality to the reflect package, and take advantage of the functionality that DeepEquals uses. I'm not a fan of Dump functions that just take an io.Writer. Why not add a named type for interface{} or reflect.Value called reflect.Deep, which implements fmt.Formatter? Then, packages that use fmt will have more precise control over formatting, and we can maybe add special formatting directives for reflect.Deep.
>> >
>> > What do you think?
>>
>> Well, we already have fmt.Printf("%#v", value).
>>
>> I don't see any obvious reason to add printing to the reflect package.
>> It doesn't require any internal information, and can be written
>> entirely separately. And, there will inevitably be a lot of desire
>> for customization of the printed output, which will lead to a complex
>> API.
>>
>> Basically: https://golang.org/doc/faq#x_in_std .
>>
>> Ian
>

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/beda96b2-9f41-41f8-a501-3090b15ed37bn%40googlegroups.com.