On Wed, Nov 8, 2017 at 4:18 PM, Albert Tedja <nicho.te...@gmail.com> wrote: > > I am writing a library that could use the benefit of context, but I also > want to add additional functionalities to the context my library using, > while keeping the same golang idiom of using With*() to create a new context > based off its parent. > > At first, it seems that all I need to do is to satisfy the context.Context > interface, but as I look deeper into the context.go source code > (https://golang.org/src/context/context.go), it looks like that I wouldn't > be able to benefit from parent's context, unless I reimplement some of the > original context.Context features, in particular its cancelCtx. > > For example, the code WithDeadline() creates a context with a deadline, > which is really just a timerCtx, whose parent is cancelCtx. The context > package also has this function called "propagateCancel()" which worries me a > bit as it looks like the parent context maintains a list of its children. > > So, if I want to create a new context with an additional feature, let's say > WithFeatureX(context.Context, X), I cannot safely create a FeatureContext > struct that can inherit from any previous contexts (possibly created from > WithDeadline/WithCancel/WithTimeout) unless I also do the same thing as what > propagateCancel() is doing. The parent context wouldn't know about the > existence of FeatureContext unless I also duplicate the propagateCancel to > include itself as a child. In other words, the relationship between the > parent context and its children is hard-coded in the context package. > > My goal is to allow users of my library to specify their own context, either > from Background() if they want just the basic, or WithTimeout() or > WithCancel(), and then pass their context to library's own custom contexts > WithFeatureX() or WithFeatureY() to add additional features, yet still > retain its original parent's ability, whatever it is. It seems to me this is > not possible without a lot of work and possibly access to the context > package private functions. > > Could you guys please let me know if my analysis is correct that > context.Context is not really designed for this purpose? Or am I just simply > wrong and overlooking something obvious?
Can you just have a field of your Context type be a value of type context.Context? Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
