-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Structs that unmarshal themselves don't work #107
Comments
There's indeed a difference in behavior, but we cannot simply break compatibility to make the behavior of the yaml package match the json package, as that would break the expectation of existing applications trusting on the implemented behavior. |
Appreciate this was 4 years ago so the odds aren't great, but.. did you find a work around for this @rojer? |
@mykter i honestly don't remember what i was trying to do at the time and what i ended up doing. sorry. |
Hi @mykter I came across this same issue and was able to work around it by casting the receiver pointer to a pointer to the alias type and then Unmarshaling in to the new pointer like so:
Hope it works for you too! |
I'm migrating code from JSON to YAML and have run into an issue with UnmarshalYAML recursing endlessly where UnmarshalJSON works.
I have a struct that has UnmarshalJSON defined and further calls into json.Unmarshal to do most of the unmarshaling, but then does some touch-up/validation afterwards.
Naive implementation does cause endless recursion, but a type alias stops it. See live example here: http://play.golang.org/p/St33ZkWvTN
note foo.ok set to true during unmarshaling which was not in the original message. this is convenient.
now, when converted to equivalent code for YAML, it goes into a recursion loop, as YAML unmarshaler seems to treat type aliases differently than JSON.
it would be nice if this use case was supported.
here's a full test program:
and output it produces:
The text was updated successfully, but these errors were encountered: