add possibility of more terse output

[kortschak]

I would be nice if it were possible to elide the unneccesary type information in goon output.

If we assume that the user has already defined the types being output (which they must have in order to use values in their source), then the leading (T) is not necessary, along with the brackets containing the value. It would be good to have an option to allow this.

[dmitshur]

I agree.

Some of go-goon output right now is too verbose. If possible, I'd like to make it more compact. The biggest offender are byte slices, perhaps they can be printed inline or so. But Go literals may be somewhat repetitive too, e.g.:

(TypeNameHere)(TypeNameHere{...})

I will think about this.

However, I don't see go-goon having configuration. It's meant to be a simple, somewhat opinionated format. If you're looking for a configurable output format, I will point you to use go-spew, the excellent library that go-goon was forked off.

[kortschak]

I'm happy for there to be no configuration, but it would be nice if there were less redundant type annotation. Though it seems that a single "short" bool would do it if you want to keep all the current annotations.

For example in cases where the type can be inferred from the context, it should not be included in my view, so (TypeNameHere)(TypeNameHere{...}) should really be TypeNameHere{...} and fields containing simple types should not have any type annotation since the context already provides that. I don't really understand what the benefit is from adding all the additional type annotation.

Unfortunately go-spew won't do the appropriate thing here (it's what I used to use and it requires a lot of editing to get the snapshots to parse as Go).

[dmitshur]

I'm happy for there to be no configuration, but it would be nice if there were less redundant type annotation. Though it seems that a single "short" bool would do it if you want to keep all the current annotations.

As I said, I agree and I am thinking about this. I need to consider all edge cases and plan this out.

For example in cases where the type can be inferred from the context, it should not be included in my view, so (TypeNameHere)(TypeNameHere{...}) should really be TypeNameHere{...} and fields containing simple types should not have any type annotation since the context already provides that.

I need to think about what happens there are complications, like pointers, etc.
Imagine (*TypeNameHere)(&TypeNameHere{...}) or so.

I don't really understand what the benefit is from adding all the additional type annotation.

It is currently that way primarily for consistency. It's always (type)(value) regardless of type and value.

[kortschak]

I forked go-spew this afternoon as github.com/kortschak/utter to do this. So if you don't want to address this for your own needs, you are welcome to close the issue.

[dmitshur]

I will watch your fork and try to adapt your solution here.

It is fairly low priority for me and I don't have a lot of time to enhance this library at this time, so your fork is a good idea, since it'll allow you to achieve what you want faster.

I'll keep this issue open since I do want to address the issue eventually.

[soroushjp]

First @shurcooL great project, this is extremely useful especially for building good tests in Go.

I'd also like to request this feature. I love begin able to copy output straight out as Go syntax but a lot of the type information is redundant and doesn't resemble idiomatic variable declarations in Go. I'm finding myself copying it in and then doing text editor magic to remove all the extra type information like (string)("my string)" --> "my string" etc. In large structs, this because quite an effort.

[dmitshur]

Thanks, glad it's helpful! :)

My plans include improving how []byte slices are printed to be more compact (and readable) than the current one uint8 value per line.

I have less problems with basic types being included because it's helpful to know "foo" is a string and not an instance of type MyCustomStringType string.

[dmitshur]

It's very worth mentioning is unconvert tool here - it can be inspiration for more terse output.

Also see mdempsky/unconvert#7.