Hi Anuj, Two quick comments.
1. FYI, in case you didn't see this in the recent vgo dependency management discussion, go fix might start to be used much more broadly in the not-too-distant future across the go community as a way to help automate in some cases the ability to update client code as a way to help manage API changes, somewhat similar to how go fix was used by the core go team before go 1.0. See the snippet pasted below from one of rsc's recent blog posts, or visit that link for a longer discussion. Not yet implemented, but could be very nice if it happens. 2. I'm mildly curious what type of changes you are trying to do, including what aspect of your intended changes makes it such that the simpler 'gofmt -r' automated refactoring or the more flexible 'eg' example-based refactoring tool (from the go team) aren't applicable. The 'eg' help is mildly annoying to track down via godoc, so forgive the volume of text but I pasted in the main help text below from 'eg' at the bottom of this post. 'eg' is focused on expression-level changes, so perhaps that is one reason it might not be applicable for you, but as I said I'm a bit curious about the specifics of your case... ======================================================== from https://research.swtch.com/vgo-import ======================================================== Before Go 1, we relied heavily on go fix, which users ran after updating to a new Go release and finding their programs no longer compiled. ... The ability to name and work with multiple incompatible versions of a package in a single program suggests a possible solution: if a v1 API function can be implemented as a wrapper around the v2 API, the wrapper implementation can double as the fix specification. For example, suppose v1 of an API has functions EnableFoo and DisableFoo and v2 replaces the pair with a single SetFoo(enabled bool). After v2 is released, v1 can be implemented as a wrapper around v2: package p // v1 import v2 "p/v2" func EnableFoo() { //go:fix v2.SetFoo(true) } func DisableFoo() { //go:fix v2.SetFoo(false) } The special //go:fix comments would indicate to go fix that the wrapper body that follows should be inlined into the call site. Then running go fix would rewrite calls to v1 EnableFoo to v2 SetFoo(true). The rewrite is easily specified and type-checked, since it is plain Go code. ======================================================== ======================================================== from golang/tools eg help via https://github.com/golang/tools/blob/release-branch.go1.10/refactor/eg/eg.go#L20 ======================================================== This tool implements example-based refactoring of expressions. The transformation is specified as a Go file defining two functions, 'before' and 'after', of identical types. Each function body consists of a single statement: either a return statement with a single (possibly multi-valued) expression, or an expression statement. The 'before' expression specifies a pattern and the 'after' expression its replacement. package P import ( "errors"; "fmt" ) func before(s string) error { return fmt.Errorf("%s", s) } func after(s string) error { return errors.New(s) } The expression statement form is useful when the expression has no result, for example: func before(msg string) { log.Fatalf("%s", msg) } func after(msg string) { log.Fatal(msg) } The parameters of both functions are wildcards that may match any expression assignable to that type. If the pattern contains multiple occurrences of the same parameter, each must match the same expression in the input for the pattern to match. If the replacement contains multiple occurrences of the same parameter, the expression will be duplicated, possibly changing the side-effects. The tool analyses all Go code in the packages specified by the arguments, replacing all occurrences of the pattern with the substitution. So, the transform above would change this input: err := fmt.Errorf("%s", "error: " + msg) to this output: err := errors.New("error: " + msg) Identifiers, including qualified identifiers (p.X) are considered to match only if they denote the same object. This allows correct matching even in the presence of dot imports, named imports and locally shadowed package names in the input program. Matching of type syntax is semantic, not syntactic: type syntax in the pattern matches type syntax in the input if the types are identical. Thus, func(x int) matches func(y int). This tool was inspired by other example-based refactoring tools, 'gofmt -r' for Go and Refaster for Java. LIMITATIONS =========== EXPRESSIVENESS Only refactorings that replace one expression with another, regardless of the expression's context, may be expressed. Refactoring arbitrary statements (or sequences of statements) is a less well-defined problem and is less amenable to this approach. A pattern that contains a function literal (and hence statements) never matches. There is no way to generalize over related types, e.g. to express that a wildcard may have any integer type, for example. It is not possible to replace an expression by one of a different type, even in contexts where this is legal, such as x in fmt.Print(x). The struct literals T{x} and T{K: x} cannot both be matched by a single template. SAFETY Verifying that a transformation does not introduce type errors is very complex in the general case. An innocuous-looking replacement of one constant by another (e.g. 1 to 2) may cause type errors relating to array types and indices, for example. The tool performs only very superficial checks of type preservation. IMPORTS Although the matching algorithm is fully aware of scoping rules, the replacement algorithm is not, so the replacement code may contain incorrect identifier syntax for imported objects if there are dot imports, named imports or locally shadowed package names in the input program. Imports are added as needed, but they are not removed as needed. Run 'goimports' on the modified file for now. Dot imports are forbidden in the template. TIPS ==== Sometimes a little creativity is required to implement the desired migration. This section lists a few tips and tricks. To remove the final parameter from a function, temporarily change the function signature so that the final parameter is variadic, as this allows legal calls both with and without the argument. Then use eg to remove the final argument from all callers, and remove the variadic parameter by hand. The reverse process can be used to add a final parameter. To add or remove parameters other than the final one, you must do it in stages: (1) declare a variant function f' with a different name and the desired parameters; (2) use eg to transform calls to f into calls to f', changing the arguments as needed; (3) change the declaration of f to match f'; (4) use eg to rename f' to f in all calls; (5) delete f'. ======================================================== --thepudds On Friday, March 16, 2018 at 9:51:58 AM UTC-4, peterGo wrote: > > Anuj Agrawal, > > Exporting an API carries a commitment to maintain and support that API. go > fix was a special-purpose command, that was useful before the Go1 > compatibility guarantee. I can see no reason to export a go fix API. > Peter > > > On Thursday, March 15, 2018 at 6:20:47 AM UTC-4, Anuj Agrawal wrote: >> >> Hi, >> >> I am looking to create a gofix for one of my projects. I thought of >> importing the code in >> https://github.com/golang/go/tree/master/src/cmd/fix so that I could >> simply write a plugin, build a binary and give it to people who import >> my code. >> >> However, I do not see any exported symbols in this code. That leaves >> me with only one choice - that I copy the code and then write the >> plugin on top of it. That does not sound like a very great idea as >> compared to being able to import the package itself. >> >> Is there any particular reason for not exporting any symbols in the gofix >> code? >> >> Thanks, >> Anuj Agrawal >> > -- 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.
