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
proposal: encoding/xml: support context on Marshaler/MarshalerAttr interfaces #64907
Comments
cc: @sebastien-rosset @as |
Possible implementation
|
The way I've typically thought about use of Trying to apply that idea to your proposal, I could see an argument that it might be useful to model "human languages preferred by the end-user" as a cross-cutting concern in that sense, but I would find it surprising for something like the XML library to directly rely on that, as opposed to the calling application making that decision and then communicating that to the XML library through a new explicit API, rather than by making the XML library accept a context and pull values out itself. I think if it seems like treating this as a cross-cutting concern is the right idea (contrary to my argument above) then it would be a good idea to identify what other libraries might make use of this new convention, and make sure the design is sufficient to serve at least a significant number of those use-cases. It seems tricky to justify considering the possibility of passing a language preference between functions as a cross cutting concern if in practice only one package would make use of it. 🤔 |
I pondered this some more after my first response and found a different way to think about it that caused me to feel more favorable about it: This proposal is not really about passing the preferred languages to the XML library, but is instead about passing that information through the XML library to some marshalling code that lives inside the calling application. In that case, the cross-cutting concern is the ability for an application to pass arbitrary data to its own unmarshalling implementations, regardless of what that data is. I can definitely identify with that need, and have used contexts to achieve similar things in the past myself, but it does always feel a little odd whenever I end up adding a context argument to a function that isn't doing interruptible I/O. I don't know of any better mechanisms for passing cross-cutting concerns in this way, though. |
Yes exactly. The specific example that I gave was for user-preferred language (which is the driving factor for me) but I also mentioned data-filtering based on other request properties. I can imagine other use-cases. Although |
Proposal Details
To some extent this is very similar to encoding/xml: context-aware XML decoders and encoding/json supports Marshaler/Unmarshaler interfaces with a context.Context. It is different in that it is specific to XML encoding but in spirit it covers both the other two as well.
func NewEncoderWithContext(ctx context.Context, w io.Writer) *Encoder
func (*Encoder) Context() context.Context
type ContextMarshalerAttr interface
containingMarshalXMLAttrWithContext(ctx context.Context, name Name) (Attr, error)
Use cases
(To paraphrase @as) An HTTP handler in a go program marshals an XML document in response to an HTTP request. To give two examples:
The context carries the i18n accepted language and the user information from which data masking policy is derived.
The response may be pre-prepared so that it may be marsahled for responses to different requests requiring different localization.
Example use
Previous rebuttals
@rsc commented on both the previous referenced proposals:
However https://go.dev/blog/context specifically documents use of contexts in this manner with regard to extracting a user IP address from a request and associating it with a
Context
so that it may be used later in the request processing by a different package.The text was updated successfully, but these errors were encountered: