breaking changes vs legacy: how gofix solved the problem with automated code transitions

Paulo Pinto pjmlp at progtools.org
Sun May 26 05:24:37 PDT 2013


Am 26.05.2013 08:32, schrieb timotheecour:
> There is a dilemma of having to choose between:
> A) getting stuck with bad names / apis / language issues forever
> B) making painful breaking changes that breaks existing code
>
> See recent D threads for all the polemics this creates on (in)stability
> of D.
>
> GO avoids this dilemma with the correct approach, IMO: automation of
> code transition.
> See this article for details on gofix:
> http://blog.golang.org/2011/04/introducing-gofix.html
>
> gofix operates on the AST of the code and performs AST manipulations (no
> fragile 'sed' / regex based bash scripts!), followed by printing them
> back to the source code. This is made possible by gofmt, which formats
> source code.
>
> Here's a snippet from the article:
>
> "Gofix has already made itself indispensable. In particular, the recent
> reflect changes would have been unpalatable without automated
> conversion, and the reflect API badly needed to be redone. Gofix gives
> us the ability to fix mistakes or completely rethink package APIs
> without worrying about the cost of converting existing code."
>
> This is what we need for D if we want to avoid getting stuck in this
> dilemma.

Before that, we need to have the compiler available as library, that is 
what Go guys kind of do.

--
Paulo


More information about the Digitalmars-d mailing list