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
encoding/xml: Omit parent tags if value is empty #4168
Labels
Milestone
Comments
I think this is working as intended. Or at least working as implemented and not possible to change now. In Vars>Var,omitempty, the omitempty here is being applied to the Var, not the whole Vars>Var. So it does omit individual empty strings from the slice: http://play.golang.org/p/ZrcLRf86Vd. At this point, I see this as something someone might have intended, and I'm reluctant to break their code to switch to this alternate meaning. So I think we have to live with this for now. It is possible to work around by using an extra element in the data structure (a pointer to a struct containing a []string, for example, or just a *[]string). Status changed to Unfortunate. |
Why hasn't this been fixed? Every single XML API is picky about extraneous tags. There is a code review here: https://golang.org/cl/6569067/ So we have a patch, but it hasn't been included? (Currently using tip) |
It seems backwards to me. If you have multiple fields referring to the same artificial parent tree, they do get included. I'm not sure why having an empty parent is useful at all. In my case it causes the API I'm working with to throw a fatal error. Doing the workaround really defeats the purpose of "omitempty" + ">". Just to make everyone happy, could we have tags like: omitempty omitempty-parent omitempty+parent Where "+parent" would mean omit this AND the parents. "-parent" would mean don't omit the parents. "omitempty" would use -parent by default, for now. |
It seems backwards to me. If you have multiple fields referring to the same artificial parent tree, they do get included. I'm not sure why having an empty parent is useful at all. In my case it causes the API I'm working with to throw a fatal error. Doing the workaround really defeats the purpose of "omitempty" + ">". Just to make everyone happy, could we have tags like: omitempty omitempty-parent omitempty+parent Where "+parent" would mean omit this AND the parents. "-parent" would mean don't omit the parents. "omitempty" would use -parent by default, for now. (Or multiple tags - Not sure how these work. "omitparent" perhaps) |
Go 1.2 is out, refreshing this request. I would like to point out that, in this case, the "omitempty" directive has actually no effect : http://play.golang.org/p/g7WhtJWEnc IMHO, the extra ",omitempty" should be taken as a clear directive in this case (1-step deep node list). Granted, I don't see a natural behavior for a deeper nested node list : type Ambiguous struct { Bees []string `xml:"Beez>Bees>Bee,omitempty"` //ok, I don't know which node should be omitted } Regarding the "break backward compatibility" part : If I'm correct : it wouldn't break the Unmarshaling of a Marshal-ed structure, it could indeed change the output of a program, but as I stated, I think this output is the one expected by the programmer if he specifies ",omitempty". Thanks. |
Russ's comments have consistently said that we aren't going to change this behaviour. This issue is closed. If you really want to reopen it, please discuss that on the golang-dev@googlegroups.com mailing list, not here in the issue tracker. Russ suggested opening a brand new issue for an omitparent tag. Please do that if you would find it useful. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by vladimir.webdev:
The text was updated successfully, but these errors were encountered: