Thanks a lot! Might i guess and try to generalize your explanations into "we tried to write a plumber for all cases possible"
Which matters a lot, in my humble opinion. At least for the various reasons you put there, simply put, because it seems not technically achievable. Still i m happy you gave me those details, they are of interest indeed. I rather intent to solve the problem on a smaller surface with more predictability, less impossible solution to find. I hope so. And if it saves 90% of the time, that s already a win, imho. May i ask another question, have you considered to create the plumbing at runtime rather than statically ? With some intents from the syntax, necessarily (and yeah go 1 compat will be a problem, let s forget it for 1 minute). I suspect in some aspects in might be handier, because it might be all about chained func calls and not type system handling, and it might be easier to interleave the ctx.check in the flaw of ops, I don t know enough to realize for sure. On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote: > > Our approach was to identify function calls that consume a Context > (indicated by a call to context.TODO in the function body) and function > calls that provide a Context (such as RPC and HTTP handlers). Then we use > the guru callgraph tool to find all call paths from context providers to > context consumers. These are the call paths that need to have a context > plumbed through them. > > Starting from a context consumer, we can work upward to the context > provider, adding a context parameter to reach intervening function > signature. Replace context.TODO in the consumer function body with the new > ctx parameter, then update all the places that call the consumer to pass > context.TODO. Now we have a new set of context consumers. Repeat until you > reach the context providers (if you reach main or a Test function, pass > context.Background instead). > > This works OK for static function calls but gets messy for dynamic calls. > If you need to add a context parameter to an interface method, now you have > to update all implementations of that method, too (guru can find these for > you). And if that interface is outside your control (like io.Writer), you > cannot change its signature, so you have to pass the context some other way > (such as via the method receiver). > > This gets yet more complicated if you cannot make atomic changes to all > callers of your functions, because callers may be in other repositories. In > this case, you must do an incremental refactoring in multiple steps: each > change to a function signature involves adding a new function that has the > context parameter, then changing all existing calls to use the new > function, while preventing new calls to the old function, so that you can > finally delete it. > > Inside Google, we ended up not needing to build all this: Context was > introduced early enough that Go users could plumb it manually where needed. > I think a context plumbing tool could still be interesting and useful to > other Go users. I'd love to see someone build it! > > S > > On Tue, May 9, 2017 at 10:54 AM <mhh...@gmail.com <javascript:>> wrote: > >> > I've done a limited form of this using awk ;-) >> >> if you have a minute, >> >> can you tell more about what limited you >> in your attempts and which trade made you stop (guessing), >> if any ? >> >> Do you still think it be awesome ? >> Or have you made your mind to an opposite position ? >> if so, For which reasons? >> >> My tool is very poor, consider it as on going, a place for inspiration to >> get started from absolutely no idea to lets get a dirty prototype. >> not sure yet how long is going to be the road, still digging :) >> >> >> On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote: >> >>> The eg tool can execute simple refactoring steps, but automating context >>> plumbing through a chain of calls is an open problem. Alan Donovan put some >>> thought into this a few years ago, and I've done a limited form of this >>> using awk ;-) >>> >> On Tue, May 9, 2017 at 6:10 AM <mhh...@gmail.com> wrote: >>> >> I want something similar too. >>>> >>>> Automatic and smart insertion of context args in a chain of calls. >>>> >>>> Methods signature updates are easy, but how to appropriately insert >>>> context check in the ast ? >>>> I m not sure yet. >>>> >>>> >>>> >The difficulty here seems to differentiate intra package calls from >>>> calls to standard/3rd party libraries which shouldn't be having new param. >>>> >>>> That does not sound too difficult, from the pkg identifier, lookup for >>>> the import path, for every import path, exists in GOROOT ? >>>> >>>> Please put updates here anything you want to share. >>>> >>>> At that moment i m using this package to help me with ast, >>>> https://github.com/mh-cbon/astutil >>>> >>>> might be a start even though it needs refactoring. >>>> >>>> >>>> On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote: >>>>> >>>>> I'm adding tracing to an existing code base with many packages and it >>>>> seems the best way to have context's passed around is to just have every >>>>> method take a context.Context. >>>>> >>>>> Is there any tooling for converting a code base/package to have: >>>>> (a) context.Context as the first parameter in each function - ctx >>>>> context.Context >>>>> (b) for any function that has changed, have its callers (within that >>>>> package) pass ctx as the first arg >>>>> >>>>> The difficulty here seems to differentiate intra package calls from >>>>> calls to standard/3rd party libraries which shouldn't be having new param. >>>>> >>>> -- >>>> 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...@googlegroups.com. >>> >>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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.
