Is there any reason for reqxml? why not BodyXML and ToXML?

[raeperd]

Hi first of all, I really appreciate your work. This package is best package I ever used in golang.

I'm trying this package for production codes, and when I try xml marshal/unmarshal, expected BodyXML/ToXML, but it does not exists. Even after I saw a previous commit that revert these API, I still think BodyXML/ToXML api is more reasonable to be used.

Also thanks to recent refactoring using Serializer/Deserializer (in this commit) it seems too trivial to implements BodyXML/ToXML using this two types just like BodyJSON/ToJSON

Is there any reason to have separate API with sub-package reqxml?

[earthboundkid]

Thank you for your kind words!

I did some testing during development, and if it were requests.BodyXML (or Builder.BodyXML) then everyone who imports requests would also include the xml package in their final binary, even if they don't use XML at all in their application. I was hoping the compiler's dead code analysis would remove it, but experimentally, that didn't seem to be true. It's not a big impact and it is a standard library package, so it's not huge deal, but it did seem unfortunate to add bloat to everyone even if people aren't using it.

The flip side of this is that everyone is stuck importing encoding/json and golang.org/x/net/html now, even if you don't use JSON in your app. JSON is very common, so I guess that's worth the tradeoff, but if I made a breaking change, I would move ToHTML to its own package too. Maybe if there's ever requests v2.

[raeperd]

Appreciates your clear answer! I didn't know than golang has such issues.
Though IMHO as you mentioned, including xml package in final binary is not a big deal.
But I still respect your decision. Hope someday go fixes this issue..