-
-
Notifications
You must be signed in to change notification settings - Fork 61
Description
Is your feature request related to a problem? Please describe.
When using a field of type time.Time or url.URL then you have to create mapping functions like this:
// goverter:converter
// goverter:extend TimeToTime
type Converter interface {
ConvertFoo(source Source) Target
}
type Source struct { CreatedAt time.Time }
type Target struct { CreatedAt time.Time }
func TimeToTime(t time.Time) time.Time {
return t
}Which is tedious. When I was first testing out goverter it was a friction point as time.Time is such a common type, but goverter was not able to handle it.
Describe the solution you'd like
A way to tell goverter that time.Time can be copied as-is. No mapping/conversion needed.
To try use your current configs, I envision it would be configured something like this:
// goverter:converter
// goverter:extend:identity time:Time
type Converter interface {
// goverter:map:identity CreatedAt
ConvertFoo(source Source) Target
}
type Source struct { CreatedAt time.Time }
type Target struct { CreatedAt time.Time }In a sense I get the "purity" of goverter's current design of not giving special treatment to any types. But I want to challenge that for some common Go stdlib types. I think it'd be super useful for the end-user if the following types were just "built-in" to use identity:
- time.Time
- net/url.URL
- error
- math/big.Int
- math/big.Float
- math/big.Rat
Describe alternatives you've considered
Maybe instead of adding new configs it would be adding a new "magic function" like:
// goverter:converter
// goverter:extend identity[time.Time]
type Converter interface {
// goverter:map CreatedAt | identity
ConvertFoo(source Source) Target
}Not too sure about that one though.
If nothing else this issue might make it easier for future devs to research what's going on with time.Time.
The docs in https://goverter.jmattheis.de/guide/unexported-field#shallow-copy does mention how to deal with time.Time, but idk maybe I'm just bad at looking up docs but I think the docs on dealing with time.Time should be more pronounced as I deem it such a common use case. (I'm also speculating on the definition of "such a common use case", but it feels super common to me at least).